fix: Show add/delete for hostname edits in activity

[mattdjenkinson]

Summary

When someone adds or removes a hostname in the DNS UI, Activity often says "updated" and names whatever is left on the object. That happens because the portal keeps one DNSRecordSet per zone per type (for example dodik-me-…-a) and puts hostnames in spec.records[]. Only the first hostname creates the object; later adds and removes are patches.

ActivityPolicy cannot see the previous object on updates, so this change has the mutating webhook compare against admission OldObject and stamp:

• activity-change: added / removed / updated
• activity-name: the FQDN that changed
• activity-value: the value for that change

Update rules prefer those annotations when present, and still fall back to display-name / display-value for older images. Pure add or remove of a hostname reads as added/deleted; value-only edits stay updated. Mixed add+remove in one write is summarized as updated.

Also switches the DNSRecordSet mutating webhook back to failurePolicy: Fail. Ignore lets admits succeed without annotations, and those activity lines never recover. Fail is appropriate now that the MWC is co-versioned with the manager image (#70); apply both from the same OCI tag.

Test plan

• go test ./internal/display/ ./internal/webhook/ ./internal/activitypolicy/
• CEL fixtures for add/remove hostname on a multi-name A object
• kustomize build config/components/admission-webhooks shows failurePolicy: Fail
• After roll: add a second A hostname on a zone → activity says added for that FQDN
• Remove that hostname while another remains → activity says deleted for the removed FQDN
• Change only the IP on an existing hostname → activity says updated
• Confirm create of a brand-new DNSRecordSet still says added (no stale activity annotations)
• Confirm webhook-down blocks DNSRecordSet writes (Fail) rather than admitting without annotations

Fixes #72
Related to #62
Related to #70