Add wallet-native Agent Identifiers and proof/payment binding

[harshalbhangale-circle]

Summary

Adds wallet-native Agent Identifiers and proof/payment binding guidance to x401.

This introduces an optional did:pkh:eip155:<chainId>:<address> Agent Identifier profile for deployments that want to bind an Agent to an EVM account. The profile is identity-only and does not change the 402 Payment Required boundary. Verifiers that accept it must treat the chain id as part of the identity and verify account control using the account's own signature rules: EIP-191/secp256k1 for EOAs and ERC-1271 for smart-contract accounts.

The PR also adds proof/payment binding guidance for routes that require both x401 proof satisfaction and a machine-payment artifact. In that case, the Verifier determines payer identity through the payment protocol's non-settling verification step, checks that it matches the bound Agent Identifier or a credential-attested authorized key/account, and rejects mismatches before settlement.

Changes

• Adds the optional Wallet-Native Agent Identifiers profile.
• Adds Proof and Payment Binding security guidance.
• Adds conditional verifier conformance bullets for combined proof and payment flows.
• Tightens the Machine Payments and 402 open question around carrier mappings, quote binding, and sequencing.
• Adds an example showing combined proof and payment on one route.

Validation

• git diff --check
• Rendered the spec successfully with spec-up

[creatornader]

I think this PR gets the main invariant right, especially keeping the Agent Identifier identity-only and requiring payer identity to match the bound Agent or an attested key before settlement.

The part I am less sure about is whether "the same unexpired verifier-issued request context" is meant to be a named binding object/reference, or just verifier-local state. If an implementation wants to test or audit this, it would be helpful to know what has to be tied together: x401 nonce/request id, route and method, Agent Identifier, payment quote, and payment artifact or receipt id.

If the exact carrier shape is intentionally out of scope, maybe the PR can say that the identity-binding invariant is settled here, while the concrete binding reference/bytes stay with the per-protocol carrier mappings.