feat: DNS activity timeline

[scotwells]

Summary

Enable activity timelines for DNS zones and records, giving users visibility into the lifecycle of their DNS configurations from creation through provider programming.

User Value

Before this change: Users could create DNS zones and records, but had no visibility into whether those configurations were successfully programmed to the DNS provider. Debugging required checking resource status conditions or watching controller logs.

After this change: Users see a human-readable activity timeline showing the complete lifecycle of their DNS resources.

Example Activity Timeline

$ kubectl activity query --filter "spec.resource.kind in ['DNSZone', 'DNSRecordSet']"
--start-time "now-1h"

TIME                  ACTIVITY
10:42:15              alice@example.com created DNS zone production-zone for domain example.com
10:42:18              DNS zone production-zone for example.com is now active with nameservers
ns1.provider.net,ns2.provider.net
10:43:02              alice@example.com created A record www-records in zone production-zone
10:43:02              alice@example.com created A record api-records in zone production-zone
10:43:05              A record www-records (www.example.com -> 203.0.113.10) is now active
10:43:05              A record api-records (api.example.com -> 203.0.113.20) is now active
10:45:30              alice@example.com created CNAME record cdn-records in zone production-zone
10:45:33              CNAME record cdn-records (cdn.example.com) is now active
11:02:17              alice@example.com updated A record www-records
11:02:19              2 A records www-records (www.example.com) are now active
11:15:44              bob@example.com created MX record mail-records in zone production-zone
11:15:51              MX record mail-records programming failed: Invalid MX target hostname
11:16:30              bob@example.com updated MX record mail-records
11:16:33              MX record mail-records (mail.example.com) is now active

User Experience

Users can now:

1. Track async operations — See when DNS changes are actually live, not just accepted
2. Debug failures — Understand why programming failed without digging through logs
3. Audit changes — Review who made what changes and when (via audit log integration)
4. Monitor rollouts — Watch activity feed during DNS migrations or bulk updates

Activity is accessible via:

• kubectl activity query — Search historical activity
• kubectl get activities --watch — Live feed of changes
• Platform UI activity timeline (when available)

Implementation Notes

• CRUD operations (create/update/delete) are captured automatically via Kubernetes audit logs
• Controller events are emitted only for async outcomes (programmed/failed) that audit logs
  cannot capture
• ActivityPolicy resources define how raw events translate to user-friendly summaries
• All event annotations use the dns.networking.miloapis.com/ prefix for DNS-specific metadata

---

Relates to datum-cloud/enhancements#469