fix(gate-57): delete six orphaned write capabilities (#530)

* fix(gate-57): delete six orphaned write capabilities

gate-57 orphaned-write-capability reported 6 findings over 55 lib/Service
files. All six had zero callers; all six are deleted.

- AangebodenGebruik\GebruikStatusHandler::updateStatus — the whole class is
  unreferenced. Its docblock says "AangebodenGebruikService delegates all
  updateStatus() logic here"; AangebodenGebruikService has no such method and
  never constructs the handler, so the method-decomposition extraction landed
  without its caller ever being updated. Deleted with the class, and with
  StatusTransitionValidator, whose only consumer it was.
- SoftwareCatalogContactSyncService::importContact — validated a UID and
  returned it unchanged. The two live consumers (OrganizationContactSyncJob,
  Repair\MigrateContactsToNc) use isAvailable/findContactByUid/
  findContactForRecord/syncToContacts, which already serve resolve-or-create.
  Spec REQ-SCNC-003 updated: the service no longer names importContact.
- SoftwareCatalogue\ContactPersonHandler::updateUserGroupsFromRoles — already
  @deprecated, logged "deprecated - role assignment now based on organization
  type" on every call, ignored both role arguments and forwarded to
  updateUserGroupsFromContactData(). No caller, so its backward compatibility
  had no consumer. Group membership is a permission fact; a second entry point
  into it is a surface, not a convenience.
- SoftwareCatalogueService::sendGebruikerWelcomeEmail,
  ::syncUserWithRevertedContact and ::updateUserFromRevertedGebruiker — each
  was a single logger->info() and nothing else. They named capabilities
  (send a welcome mail, reconcile a user after an object revert) that have
  never been implemented; wiring a log line in would have hidden the gap.

⚠️ SoftwareCatalogEventListenerTest asserted that the listener calls
sendGebruikerWelcomeEmail, syncUserWithRevertedContact and
updateUserFromRevertedGebruiker exactly once each. It does not, and there is no
code path in SoftwareCatalogEventListener that ever did — the tests described a
wiring that does not exist. They are corrected here rather than deleted: the
revert case now asserts the true invariant (the revert path runs without
reaching a capability the app does not implement).

Before: 6 findings over 55 files. After: 0 findings over 53 files (two service
files fewer because the dead handler pair was deleted).

* style(catalogue): capitalise two inline comments

Two pre-existing phpcs errors ('Inline comments must start with a capital
letter') in a file this branch already touches, per the fix-what-you-touch
rule. lib/Service/SoftwareCatalogueService.php is now phpcs-clean (0 errors).

Author: rubenvdlinde

lib/Service/AangebodenGebruik/GebruikStatusHandler.php

@@ -113,35 +113,18 @@ public function searchContacts(string $query): array {
 		return $contacts;
 	}//end searchContacts()
 
-	/**
-	 * Import (resolve) a Nextcloud contact UID into a catalog relationship
-	 * record's `contactsUid`. Idempotent: an already-known UID is returned
-	 * unchanged. An unknown UID raises a RuntimeException.
-	 *
-	 * @param string $uid The contact UID to import.
-	 * @param ?string $addressBookKey Optional addressbook key (kept for parity
-	 *                                with the canonical signature; unused here).
-	 *
-	 * @return string The resolved contacts UID.
-	 *
-	 * @throws RuntimeException When Contacts is disabled or the UID is unknown.
-	 *
-	 * @SuppressWarnings(PHPMD.UnusedFormalParameter) — $addressBookKey kept for canonical-signature parity.
-	 *
-	 * @spec openspec/specs/softwarecatalog-contacts-to-nc/spec.md
+	/*
+	 * NO importContact() HERE.
+	 *
+	 * It validated that a UID resolved and returned that same UID unchanged —
+	 * no import, no write. It had no caller: the two live consumers,
+	 * `BackgroundJob\OrganizationContactSyncJob` and `Repair\MigrateContactsToNc`,
+	 * use `isAvailable()`, `findContactByUid()`, `findContactForRecord()` and
+	 * `syncToContacts()`, which together already serve the capability
+	 * ("resolve or create the Nextcloud Contact for a record and return its
+	 * UID"). A third entry point would have duplicated `syncToContacts()`
+	 * without its create path.
 	 */
-	public function importContact(string $uid, ?string $addressBookKey = null): string {
-		if ($this->isAvailable() === false) {
-			throw new RuntimeException('Nextcloud Contacts is not available');
-		}
-
-		$contact = $this->findContactByUid(uid: $uid);
-		if ($contact === null) {
-			throw new RuntimeException('Contact not found in any accessible addressbook');
-		}
-
-		return $uid;
-	}//end importContact()
 
 	/**
 	 * Resolve (or create) the Nextcloud Contact for a catalog relationship

lib/Service/AangebodenGebruik/StatusTransitionValidator.php

@@ -950,51 +950,17 @@ public function updateUserGroupsFromContactData(\OCP\IUser $user, array $contact
 		}//end try
 	}//end updateUserGroupsFromContactData()
 
-	/**
-	 * Legacy method for backward compatibility - now redirects to organization type-based logic
-	 *
-	 * @param \OCP\IUser $user The user to update
-	 * @param array $newRoles The new roles (ignored - kept for compatibility)
-	 * @param array $oldRoles The old roles (ignored - kept for compatibility)
-	 *
-	 * @return void
-	 * @deprecated Use updateUserGroupsFromContactData instead
-	 * @spec       openspec/specs/sc-handlers/spec.md
+	/*
+	 * NO updateUserGroupsFromRoles() HERE.
+	 *
+	 * It was already `@deprecated`, logged "role assignment now based on
+	 * organization type" on every call, ignored both of its `$newRoles` /
+	 * `$oldRoles` arguments, and forwarded to
+	 * `updateUserGroupsFromContactData()` — the live method. It had no caller,
+	 * so the backward compatibility it existed for had no consumer either.
+	 * Group membership is a permission fact; a second, role-shaped entry point
+	 * into it is a surface, not a convenience.
 	 */
-	public function updateUserGroupsFromRoles(\OCP\IUser $user, array $newRoles, array $oldRoles = []): void {
-		$this->_logger->info(
-			'updateUserGroupsFromRoles is deprecated - role assignment now based on organization type',
-			[
-				'username' => $user->getUID(),
-				'newRoles' => $newRoles,
-				'oldRoles' => $oldRoles,
-			]
-		);
-
-		// For backward compatibility, try to find the user's contact data and update based on organization type.
-		try {
-			$contactObject = $this->findContactPersonByUsername(username: $user->getUID());
-			if (empty($contactObject) === true) {
-				$this->_logger->warning(
-					'Could not find contact person data for user - cannot update groups',
-					['username' => $user->getUID()]
-				);
-			}
-
-			if (empty($contactObject) === false) {
-				$contactData = $contactObject->getObject();
-				$this->updateUserGroupsFromContactData(user: $user, contactData: $contactData);
-			}
-		} catch (\Exception $e) {
-			$this->_logger->error(
-				'Failed to update user groups via legacy method: ' . $e->getMessage(),
-				[
-					'username' => $user->getUID(),
-					'exception' => $e,
-				]
-			);
-		}//end try
-	}//end updateUserGroupsFromRoles()
 
 	/**
 	 * Finds contactpersoon object by username