New 'safeguards' capability family for permissions and remote control

What

• The permission-context capability record used throughout Claude Code gains a fourth flag, safeguards, alongside the existing remoteTools, hooks, and plugins flags. It gates whether the model's safety/safeguards classification data is attached to a payload.
• Remote Control's device-attestation and settings-diffing machinery gains a matching safeguards family, used to police apply_flag_settings requests from a paired bridge client that try to weaken safeguards-related settings, and to strip forwarded plugin-marketplace or safeguard settings unless the connection's capabilities explicitly allow them. A new default-capabilities object turns remoteTools, hooks, plugins, and safeguards off by default.
• The remote transport's flag-settings trust object also gained a safeguards trust category, deciding whether an untrusted or unverified peer may disable safeguards via apply_flag_settings; any below-floor change that can't be verified is dropped and logged rather than applied.
• A new no-op event-filter hook now runs on every incoming bridge session frame before existing verification logic; it currently does nothing but is now part of the frame-handling pipeline.

Why This lays the groundwork for treating "safeguards" (the model's safety classification data) as its own protected capability, matching how remote tools, hooks, and plugins are already gated, so a remote/bridge connection can't silently weaken or disable safety-related settings unless explicitly trusted to. The actual checklist of settings this protects is currently empty, so the gate exists but doesn't yet block anything in this build.