feat(projects): add ServiceAccount and ServiceAccountAccessToken

[markussiebert]

Description

Adds project-scoped ServiceAccount and ServiceAccountAccessToken managed
resources, completing the service-account family alongside the group resources
(#326) and the instance resources (#368).

• ServiceAccount — manages a GitLab project service account.
• ServiceAccountAccessToken — manages the personal access token of a
  project service account, keyed by serviceAccountId. Two modes, selected
  automatically:
  • Owner mode (default): the ProviderConfig authenticates with a token that
    can manage the project's service-account tokens; create/observe/rotate/revoke
    go through the project service-account token endpoints.
  • Self mode: the ProviderConfig authenticates with the very token this
    resource manages (self-sustaining rotation loop) and uses the self
    endpoints.

Both cluster-scoped and namespaced variants are generated.

Notes for reviewers

The ServiceAccountAccessToken implementation mirrors the group resource from
#326 (it is the same logic with Group → Project renames). The review fixes
raised on #326 are included here from the start:

• UseLegacyProviderConfig populates CredentialsSecretRef (self-mode detection
  depends on it) — inherited from master.
• Self-mode safety guard: refuse to manage the token when it does not belong to
  spec.forProvider.serviceAccountId (guards against a miswired credentials
  secret rotating/revoking the wrong service account's token).
• Owner-mode rotation only falls back to a fresh create when the existing token
  is genuinely gone (404, or 400 "token already revoked"); any other error
  surfaces rather than silently minting a second token.
• The owner-mode list filters server-side with state=active.
• Cluster-scope self-mode detection compares the write reference's namespace
  (w.Namespace) instead of cr.GetNamespace(), since cluster-scoped resources
  have no namespace.

How was it tested

• go build ./..., go vet ./... — clean.
• go test ./... — full suite passes.
• Unit tests cover self-mode service-account match/mismatch and owner-mode
  rotation fall-through (404 and 400-revoked), in both namespaced and cluster
  scopes.

[derbauer97]

Review + live e2e battle-test

Reviewed and ran a full end-to-end test on the same setup as #368: kind + Crossplane 2.3.3, provider out-of-cluster against a self-managed GitLab 18.11.5-ee instance, exercising both the namespaced (projects.gitlab.m.crossplane.io) and cluster-scoped (projects.gitlab.crossplane.io) variants of both new resources.

This one is in good shape. Crucially, it mirrors the group resource (#326) using scoped project endpoints, so it does not carry the rotate-ownership issue I flagged on the instance PR (#368).

Verified working end-to-end

ServiceAccount (scoped *ProjectServiceAccount* endpoints):

• Create -> Ready/Synced, SA created in the project, atProvider populated.
• Update -> renaming via spec.forProvider.name propagates to GitLab; resource stays stable (no condition flapping / drift loop).

ServiceAccountAccessToken:

• Owner mode: create/observe -> Ready/Synced, token authenticates as the project service account (user_id matches), written to a connection.crossplane.io/v1alpha1 secret.
• Self mode: auto-detection (SelfManaged=True) + self-rotation (token id changes, new value written back, loop stays Ready/Synced).
• Self-mode service-account mismatch guard: refuses with the terminal error, no rotate/revoke.
• CEL: projectId/serviceAccountId/name/scopes immutable; expiresAt XOR renewalPeriodDays and the renewBeforeDays dependency rules enforced.

Security: the #368 rotate-ownership issue does NOT apply here

On #368 I showed that a drifted/attacker-set crossplane.io/external-name made the instance controller rotate an arbitrary instance token (via the unscoped admin RotatePersonalAccessTokenByID) and leak it into the tenant secret. I tried the same exploit here:

• Drifted external-name to a token id owned by an admin user, while serviceAccountId = the project SA.
• The scoped RotateProjectServiceAccountPersonalAccessToken(project, sa, id) returned 404 for the foreign id, so the controller fell back to creating a fresh token for the correct SA. The foreign token was left untouched (active:true), and the connection secret got a token owned by the intended SA — not the admin.

I also confirmed owner-mode create with a serviceAccountId that isn't a project service account (a human admin) fails with 404 Not Found and writes no token — so the "mints PATs for arbitrary users" concern from #368 doesn't apply either; the scoped create endpoint validates membership for you.

In short, by keeping the group resource's scoped endpoints (rather than unscoped admin by-id), this PR avoids both #368 findings by construction. 👍

Minor (non-blocking)

• The self-mode example in examples/projects/serviceaccountaccesstoken.yaml omits serviceAccountId, which disables the self-mode mismatch guard in the shipped example. Suggest setting it (same note I left on feat(instance): add ServiceAccountAccessToken managed resource #368).
• No shortName on the new project CRDs (group SAAT has saat); a short name would be a small kubectl UX win.

Open question

• ServiceAccount leaves name/username mutable (only email is +immutable, and that's a doc marker, not CEL-enforced). Intentional? GitLab generates username/email when unset; leaving them unset reconciled cleanly in my test, but worth confirming you want rename-in-place semantics rather than immutability.