Attestation status handling simplified; unattested senders are now explicitly held back

What

• Remote session control-request handling no longer passes raw attestation data (attestationRaw) to served-channel requests (tool/dialog serving); only the resolved attestationStatus is passed now.
• Telemetry for remote tool calls likewise no longer includes attestationRaw, only attestationStatus and other fields.
• Deriving a device's attestation status was simplified to a direct uppercase pass to the classifier, dropping a prefix-stripping/raw-value side channel, and this now also applies to hook_callback subtypes, not just the previous allow-list.
• The device-hooks dispatcher now checks whether the sender is "held back" due to attestation status; if so, it logs that it is holding back and returns no opinion instead of running its normal dispatch and muted checks.
• The error message shown when a remote tool call is rejected for lacking attestation was simplified from describing an account-level requirement to a simpler statement about a missing device signature.
• A new message explains that hooks are skipped for a cloud session because the service could not vouch for the sender under the organization's trusted-device policy.

Why

This tightens and simplifies how Claude Code decides whether a remote or cloud request, or a hook's sender, can be trusted, and gives clearer explanations when something is blocked because a device couldn't be verified.