fix: null-guard responseObject.metadata.name in ActivityPolicy creates

[ecv]

What

Make the create rule summaries null-safe in six ActivityPolicies that
dereference audit.responseObject.metadata.name. Guard the leaf and fall back
to audit.objectRef.name.

Why

Same DLQ-leak class as the prod DLQSlowLeak on the NSO gateway policy
(milo-os/activity#212). A create rule matches on verb/requestObject, so a
rejected create (409/422/admission-deny) still matches — but the apiserver
returns a Status object as responseObject with no metadata.name. CEL
raises no such key: name, the event goes to the DLQ, and retries fail
identically. Latent until the first rejected create of each kind.

Fixed (create rules)

• config/services/activity/policies/resourcemanager/ — project, organization
• config/services/activity/policies/iam/ — role, group, serviceaccount
• config/services/identity/policies/ — serviceaccount

Remediation

Merge + milo release → the milo-activity-policies Flux Kustomization
re-applies the corrected CRs; processor retries any DLQ backlog. No kubectl.

Related

• NSO fix (gateway + 5 more): fix: null-guard responseObject derefs across NSO ActivityPolicies (DLQ leak) datum-cloud/network-services-operator#230
• billing fix: milo-os/billing (separate PR)
• Runbook fix: fix: correct DLQ runbook CEL null-check guidance activity#213 · Investigation: fix: gateway ActivityPolicy summary CEL leaks DLQ on events missing responseObject.metadata.name activity#212

[ecv]

Blast radius + suggested follow-up (not in this PR)

While extending this fix (added responseObject.details.name fallback for generateName creates rejected before naming — see latest commit), I swept the rest of the activity policies for the same responseObject deref bug class. Summary of what's left:

Already safe — these non-create rules deref responseObject but their match clause guards it down to the ref object, so a rejected/Status response never reaches the summary:

• resourcemanager/organizationmembership (delete) — has(responseObject.spec) && has(responseObject.spec.userRef)
• notification/contactgroupmembership (delete) — guards contactRef + contactGroupRef
• iam/groupmembership (delete) — guards userRef + groupRef
• iam/userdeactivation (delete) — guards userRef
• quota/resourcegrant (delete) — guards consumerRef
• iam/userinvitation (accept/decline/cancel) — guards responseObject.status.organization.displayName fully → safe

Residual (low-probability) gap: each of the above derefs one level deeper than its match guards — e.g. match checks ...spec.userRef, summary uses ...spec.userRef.name. If the ref object is ever present without name, CEL raises no such key: name → DLQ. In practice refs always carry a name, so this is latent, not active. No DLQ evidence for these.

Recommendation: a separate follow-up to push each guard to the leaf (&& has(...userRef.name)) or fall the summary back to objectRef.name. Out of scope for this PR — flagging so it's tracked, not pursuing it here.