test: add ServiceAccount contract test from infra (WIP)

[ecv]

WIP / DRAFT — migration in progress, do not merge yet.

What

Adds a thin iam.miloapis.com ServiceAccount API-contract test at test/iam/service-account-contract/, migrated from the infra service-account-lifecycle test.

Flow: create Organization + User + OrganizationMembership → create Project in the org control plane (ServiceAccount is a Project-context resource) → wait Ready → on the project control plane: create a ServiceAccount, assert spec.state defaults to Active, then delete it and assert it is gone.

Why

Per datum-cloud/infra#3006, single-service API-contract tests are being evacuated from infra's live-env suite to their owning repos and run against milo's local apiserver pre-merge. Milo owns and serves the iam.miloapis.com ServiceAccount contract on project control planes.

Scope deliberately reduced. The infra original also drove datumctl key issuance, authenticated as the service account with the issued key, and revoked the key. Those require the auth service (Zitadel), which is absent in the local env. That key-issuance / auth / revoke roundtrip intentionally remains an infra "construct" test (still skipped until datumctl gains the commands), per infra#3006. This PR ports only the contract milo can serve locally.

Refs:

• datum-cloud/infra#3006 (consolidation / evacuation)
• datum-cloud/infra#3005

GVK confirmed

apiVersion: iam.miloapis.com/v1alpha1, kind: ServiceAccount — confirmed via config/crd/bases/iam/iam.miloapis.com_serviceaccounts.yaml:

• scope: Cluster (so the manifest sets no namespace)
• discovery.miloapis.com/parent-contexts: Project → served on the project control plane, hence the project-CP setup
• spec.state defaults to Active

Adaptation from the infra original

• Dropped all datumctl steps (SA create/keys/auth/revoke/delete) and live-auth kubeconfig plumbing.
• Reaches the org + project control planes served by the local apiserver directly.
• Removed spec.skip: true; added Organization/User/OrganizationMembership/Project fixtures; added a spec.description; zero inline comments per repo convention.

chainsaw lint: passes.

Known-uncertain

• No Ready/status.email assertion. status.email and the Ready condition on a ServiceAccount are populated by the auth-provider integration (Zitadel), which is absent locally — no in-tree milo controller sets them. The test therefore asserts only the create/default/delete contract. If the local env is later wired with an auth provider, a Ready/status.email assertion could be added (behind the requires=authorization-provider selector).
• Not executed end-to-end in this branch (no live green CI run — do not block on CI here). If ServiceAccount CREATE is admission-gated on an OpenFGA authz check in the local env, this test may need the test.<...>/requires: authorization-provider label so the harness skips it when the authz provider is absent.

[ecv]

⚠️ Action required before this leaves draft

1. This is a deliberate split, not a full migration. Only the ServiceAccount API
   contract (create → assert state: Active default → delete → assert gone) moves here.
   The datumctl key-issuance / auth / revoke / verify-rejected roundtrip from the original
   infra test stays in infra as a construct test (it needs the auth provider / Zitadel,
   absent in milo local env). infra#3006's disposition note is being updated to reflect this.
2. Ready / status.email are not settable locally — they come from the auth-provider
   integration; no in-tree milo controller sets them. Hence the test asserts create/default/
   delete only. Confirm that's the intended contract scope for the local suite.
3. Possible OpenFGA gate. If ServiceAccount CREATE is authorization-gated locally, this
   test needs the requires: authorization-provider selector label (the suite runs with
   --selector "requires!=authorization-provider"). Verify against a running local apiserver.

Not run end-to-end yet (only chainsaw lint). Tracks datum-cloud/infra#3006.