feat: Let users query their own audit logs from the activity service

[ecv]

Summary

Users should be able to query their own audit logs, but granting that through the shared self-manage role ties the core control plane to the activity service, which deploys after it.

An earlier attempt, #677, added the grant to that shared role from the activity deployment, and because Flux applies both deployments as one owner, each strips the other's fields on every reconcile, so the role swings between having audit access and losing every other permission.

This change gives the activity service its own role for the access and binds each user to it for their own account only.

When the activity service is not deployed, the binding is skipped and the core control plane carries nothing of it.

Test plan

• A user can query their own audit logs and no one else's
• Repeated reconciles of both deployments leave the shared self-manage role unchanged
• Without the activity service, users are created normally and get no audit binding
• Deleting a user removes their audit binding

Fixes #676

[ecv]

Detail moved out of the description.

Why #677 fails. It added a partial Role/iam-user-self-manage (only spec.inheritedRoles) to the activity overlay and relied on server-side apply to merge that entry into the core role. In datum-cloud/infra the core role is applied by the milo-core-control-plane-crds Flux Kustomization and the partial by milo-activity-policies. Flux's kustomize-controller applies every Kustomization under one shared field manager, so each apply prunes the fields the other owns, on every reconcile (interval: 1h each):

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 is listType=map, which merges cleanly only across distinct field managers, and Flux does not provide them here.

What this change does:

• config/services/activity/roles/activity-self-audit-log-querier.yaml adds a standalone Role inheriting activity.miloapis.com-audit-log-querier. One object with one owner, so no contention.
• config/services/activity/kustomization.yaml wires it into the activity overlay.
• user_webhook.go binds each user to that Role, scoped to their own User resource, mirroring the user-self-manage PolicyBinding. The role name is configurable, and empty skips the binding, so the core control plane carries no activity coupling.
• user_controller.go sets an owner reference on the binding for garbage collection on user deletion, guarded by IsNotFound so it is inert without the activity overlay.

Rejected alternative. One PolicyBinding to system:authenticated, like organization-creator-policy, needs no per-user code, but a Group subject only allows resourceKind: User, which would let every user query every user's audit logs.

Validation so far: go build on the edited packages is clean, and task generate:code produces no manifest diff.

Supersedes #677. Part of datum-cloud/infra#2943 and datum-cloud/infra#2939.

[scotwells]

You shouldn't need to create a separate policy binding for this. It should be granted through role inheritance on the user self-manage role. It should be patched on the infra layer so the system's are de-coupled.

[ecv]

better yes