Feature: revocable delegated buyer signing without exporting PrivateNote keys

[Community-AI-tools]

Problem

AI Market needs a safe managed-custody route where a user can confirm a bounded inference purchase in one click while the platform executes it using a controlled service-owned Note. Current dexdo buy requires the raw --note-key for owner checks, challenge, placement, and handover. Sending a user's seed or PrivateNote key to a website/server is unacceptable, and a browser cannot safely read another DexDo tab's private state.

Proposal

Add a revocable, scoped buyer delegation / signer abstraction for inference buys.

The Note owner should sign a delegation grant that binds:

• delegate public key (or a remote signer identity), nonce, expiry/TTL;
• operation: inference buy only;
• token/model or explicit resource scope;
• maximum unit price, total spend, and operation count;
• canonical purchase intent / deal identity and replay protection;
• on-chain consumption of the grant and owner-controlled revocation.

The PrivateNote/gateway should accept the delegate only for the buyer-side writes covered by that grant. The same delegate identity must remain bound through the challenge/IOB/handover flow.

CLI/API shape

Please expose a signer abstraction so dexdo buy does not require a raw --note-key in the caller process. A remote signer or delegated-key transport is sufficient if it preserves the limits above and never logs/export secrets.

Delegation must not authorize withdrawal, changeOwner, Note provisioning/reclaim, dispute settlement, or any unrelated operation. Existing self-custody usage must remain the default and fully compatible.

Acceptance cases

• expired, revoked, replayed, stale-quote, over-price, over-total, and concurrent use attempts fail closed;
• successful use consumes the bounded grant exactly once;
• tests cover buyer owner-check, challenge, placement, and handover binding;
• no secret appears in CLI output, logs, config, or diagnostics.

Context: AI Market has an internal preflight/lifecycle request in #81. This proposal targets the published v0.0.17 source revision fb2d86d4a596712bfe489c2eac45d5e22df9bc22; it is a separate capability, not a claim that #81 is insufficient.