Track Unix socket full enforcement separately from CO-RE migration

[yairfalse]

Summary

Thread 3 (CO-RE migration) is done and should ship independently.

Thread 2 (Unix socket full enforcement) should stay tracked separately because it is a behavior/enforcement change, not just portability or loader cleanup.

Why this should not block shipping thread 3

• The CO-RE work removed the runtime kernel offset plumbing and kept the existing unix enforcement behavior intact.
• Shipping that separately reduces risk and makes regressions easier to localize.
• Thread 2 still needs explicit product and kernel-path decisions around peer resolution and self-test semantics.

Current state

• sock->sk_cgrp_data.cgroup is now read through generated bindings as part of the CO-RE migration.
• We did not implement the unix_sock.peer path described in AGENT.md thread 2.
• The current unix hook continues to enforce based on the server/listener socket cgroup path already in use.

Follow-up work for thread 2

1. Decide whether the enforcement model should switch from the current other->sk_cgrp_data.cgroup path to explicit unix_sock.peer resolution.
2. If yes, add the required kernel bindings / access path for unix_sock.peer and update the hook implementation.
3. Revisit the unix self-test so it verifies the intended peer-resolution semantics rather than only a non-zero cgroup id.
4. Add targeted tests for cross-zone unix socket allow/deny behavior and host/unzoned peers.

Rationale for tracking separately

This is a semantic enforcement change with verifier and kernel-layout implications. It deserves its own review, test plan, and rollback boundary instead of piggybacking on the already-finished CO-RE migration.