feat(iam): re-home audit-log-querier grant to a standalone activity role (replaces #677)

[ecv]

Summary

Replaces #677. Closes #676.

Delivers the "users can query their own audit logs" capability from the activity service overlay without mutating the shared iam-user-self-manage Role — keeping the foundational milo control plane free of any activity dependency.

Why #677 doesn't work

#677 added a partial Role/iam-user-self-manage manifest (only spec.inheritedRoles) to the activity overlay and relied on server-side apply to merge that single entry into the core role.

That assumption fails under the actual GitOps setup (datum-cloud/infra):

• The core role is applied by the milo-core-control-plane-crds Flux Kustomization (./crd/overlays/core-control-plane → ../../../roles).
• The partial overlay would be applied by milo-activity-policies (./services/activity).
• Flux's kustomize-controller server-side-applies every Kustomization under a single shared field manager (kustomize-controller) — there is no per-Kustomization manager and no field-manager override on the Kustomization spec.

With one shared manager, each apply re-declares its full field set, so SSA prunes any field that manager owned but no longer lists. The two Kustomizations therefore prune each other's fields on every reconcile (interval: 1h each). The role flip-flops:

After reconcile of…	Result
milo-core-control-plane-crds	includedPermissions present, audit inheritance gone
milo-activity-policies	audit inheritance present, all self-manage permissions gone

inheritedRoles being listType=map only enables clean merge across distinct field managers owning distinct keys — which Flux does not provide here. (The companion infra PR's premise that inheritedRoles is "an atomic list" is also incorrect — it is map-type — but the shared-field-manager problem stands regardless.)

What this PR does instead

• New: config/services/activity/roles/activity-self-audit-log-querier.yaml — a standalone Role that inherits activity.miloapis.com-audit-log-querier. A distinct object with a single owner → no cross-Kustomization field contention.
• Edit: config/services/activity/kustomization.yaml — wires the role into the activity overlay.
• Webhook (user_webhook.go): grants the role per-user, scoped to the user's own User resource, mirroring the existing user-self-manage PolicyBinding, so self-audit access stays self-scoped. Gated on a configurable role name (empty → skip), so the core control plane carries zero activity coupling when activity is not deployed.
• Controller (user_controller.go): attaches an owner reference to the binding for GC on user deletion, IsNotFound-guarded so it is inert when the activity overlay is absent.

Why not a static group binding

A single PolicyBinding to system:authenticated (like organization-creator-policy) needs no per-user code — but only resourceKind: User is available for a Group subject, which would grant every user query access to all users' audit logs. Rejected as a scope regression.

Validation

• go build on edited packages → clean.
• task generate:code → no manifest diff (no new API types/markers).
• Full builds/tests via CI.

Coordination

• Part of: datum-cloud/infra#2943, datum-cloud/infra#2939.
• Pairs with: datum-cloud/infra#2953 (its "atomic list" justification should be corrected to "map-type, but shared Flux field manager").

🤖 Generated with Claude Code