docs(specs): define the upto scheme for BSV

[linzhm]

Description

Add the BSV upto network specification alongside exact: the payer authorizes a maximum once, the recipient determines the actual service amount after execution, and one terminal transaction settles the authorization. Its complete Atomic BEEF is returned to the payer through the existing settlement response. Application streaming can reuse the cap signatures across complete conflicting candidates; it does not introduce a scheme, session, or extra x402 round trip.

Scope: only specs/schemes/upto/scheme_upto_bsv.md. No implementation, generic specification, or exact behavior changes are included.

Fork review and merge boundary

This Draft targets bsv-blockchain/x402, not x402-foundation/x402. It is the first of two sequential contributions; the TypeScript implementation remains local while this specification is reviewed.

The temporary base is feat/bsv-exact-scheme at df5fdb3ce5573da40f0eea5eb92e4078c7f18fad, so the review shows only this specification. The fork's main does not yet contain BSV exact. Do not merge this Draft into the current base while it is the head of the existing upstream exact PR (number 2890): doing so would expand that PR. Before merge, retarget to a separate BSV integration branch at the same exact baseline, or to the appropriate branch after exact has landed. No review request or upstream-ready claim is made.

Protocol decision

Does this enforcement split satisfy generic upto?

Property	BSV construction
Maximum	Cap signatures mechanically limit total payer exposure E. Conforming verification enforces service amount A <= M; normally E > M supplies fee headroom. A malicious control-key holder can construct a Script-valid allocation above M, up to E.
Recipient	A control input binds completion authority to the key derived from payTo; cap signatures do not covenant the later recipient outputs.
Time	Signed terms contain the validity window, which participants enforce. Cap signatures do not expire cryptographically; final sequences disable nLockTime.

If the generic scheme requires Script to prevent all three violations, this proposed profile does not meet that requirement. This PR does not amend the generic specification to grant itself an exception.

Atomic single-use coordination and authenticated recipient-controlled settlement are deployment requirements. Uncertain selection fails closed; there is no business-response recovery or exactly-once wallet-effect promise. Transaction possession and propagation incentives are background assumptions, not proof of wallet acceptance or reliable data retention.

Tests

• Specification Prettier and whitespace checks pass.
• The canonical digest known-answer vector is covered by the separately prepared reference implementation tests.
• Generic upto and BSV exact specifications are unchanged.
• One file added, 633 lines; no implementation tests are presented as approval of this specification.

Checklist

• Specification formatted and checked
• Commits signed and GitHub verification checked before opening
• Docs-only change; no changeset needed
• Human author has personally reviewed the complete specification
• Enforcement split accepted by maintainers
• Safe merge base established; no unintended change to the existing upstream exact PR

Significant AI assistance was used for drafting and independent local review. Human author verification remains required before requesting non-Draft review.