Naming: capability_issuer vs issuer

Payload::issuer is the key that signed a particular delegation, while Payload::capability_issuer() is the root of the chain: the key whose authority the delegation passes along (CapabilityOrigin::Issuer → the issuer itself, CapabilityOrigin::Delegation(root) → that root). The two names are easy to confuse even though they mean structurally different things — the issuer changes at every hop, the capability issuer stays constant along a valid chain.

This tension is inherited from v1, which already used two vocabularies for the same concept: the API says "capability issuer" (capability_issuer(), WrongCapabilityIssuer), but the human-facing spots say "owner" (delegating_builder(issuer, audience, owner, capability) and the chain walk comment "they start with the owner of the capability").

Candidates:

• capability_owner() — resolves the inconsistency in favor of the word the code already uses informally; cannot be confused with issuer. Error variant becomes WrongCapabilityOwner.
• subject — UCAN's term for this role (sub), and the test subject_must_be_the_authorizer already uses the word. Downside: X.509 readers expect "subject" to mean the key being certified, which is closer to audience.
• root / chain_root — names the chain position rather than the role; reads oddly on a single self-describing link.

Since v2 is a breaking release anyway, there is no compat reason to keep the v1 name.

Start by locating Payload::issuer, Payload::capability_issuer(), CapabilityOrigin, WrongCapabilityIssuer, and delegating_builder. Read the subject_must_be_the_authorizer test and trace the chain-walk behavior before deciding which vocabulary is consistent. Done means the selected name and related error or call sites are applied consistently without changing the issuer and capability-root distinction.