docs: SPEC 6.1.1/6.2/6.3/6.4 + README + CHANGELOG for the owned-approval shape

Delete the two SPEC carve-outs that stop being true (enforcement is opt-in; the
authorization is not bound to the signed bytes) and the closed "undeclared intent is not
escalatable" shape gap. SPEC 6.2 states the enforcement point 6.2's MUST previously
lacked; 6.3 states the three outcomes; new 6.3.1 records the normative crate-outcome ->
wire-code mapping including SPEND_POLICY_INDETERMINATE -33056, which a host must add to
its own SPEND_* taxonomy (this crate carries none).

Co-Authored-By: Claude <noreply@anthropic.com>

Author: MichaelTaylor3d

CHANGELOG.md

@@ -4,6 +4,59 @@ All notable changes to this project are documented here.
 This project adheres to [Semantic Versioning](https://semver.org) and
 [Conventional Commits](https://www.conventionalcommits.org).
 
+## [0.2.0] - 2026-07-27
+
+### BREAKING CHANGES
+
+The custody gate now returns a RULING and mints an approval that OWNS the coin spends it
+authorized, and that approval is the only thing the signer accepts. A `0.x` MINOR is
+semver-breaking, so every consumer must move: `^0.1` cannot resolve `0.2.0`.
+
+- `PolicyAuthorizer::authorize_op` now takes `&[CoinSpend]` (not `&SpendSummary`) and returns
+  `Result<SpendRuling>` (not `Result<()>`). It derives the summary itself, so there is no
+  caller-supplied description for it to disagree with.
+- **`MoneySigner::sign_coin_spends` is REMOVED.** `sign_approved(SpendApproval) -> SpendBundle`
+  is the only signing entry point; no function anywhere turns `&[CoinSpend]` into a signature.
+- **The `SpendAuthorizer` trait is REMOVED.** A custody gate must not be an interface whose
+  simplest implementation approves everything — the crate's only consumer had shipped exactly
+  that (a default authorizer whose entire body was `Ok(())`), so every bound this crate
+  advertised was absent from the running application.
+- **`AccountError::RequireAuth` is REMOVED.** "Not yet — ask the human" is now
+  `SpendRuling::RequiresConfirmation`, an `Ok` value. As an error it forced consumers to collapse
+  it into a refusal, which made the confirm ceremony unreachable for exactly the `Confirm` and
+  `Vault` tiers that exist to require it.
+- `LocalMoneySigner::sign_unsigned` is now `pub(crate)`: it accepted a caller-supplied summary,
+  which was the same defect one layer over.
+
+Migration: replace `authorize(&summary)` / `authorize_op(&summary, class)` with
+`authorize_op(&coin_spends, class)`; match the ruling — `Approved(approval)` → `sign_approved`,
+`RequiresConfirmation(pending)` → render `pending.summary()`, then
+`pending.confirmed(decision)`. Delete any fake authorizer and drive the real gate with a test
+policy plus the public `FixedClock`.
+
+### Features
+- **wallet:** The gate mints an owned `SpendApproval`; the signer accepts nothing else
+- **wallet:** `SpendRuling` carries the escalatable third outcome, so a `Confirm`/`Vault` spend
+  reaches the confirm ceremony
+- **wallet:** `SpendOpClass::Undeclared` escalates to the human rather than dead-ending, so a
+  request from outside the process is confirmable rather than unspendable
+- **wallet:** `AutoSendPolicy::configured_limits` — the `Option` form of the op-class lookup
+
+### Fixes
+- **wallet:** Refuse a spend whose input coin amounts do not sum in a `u64`. `dig-wallet-backend`
+  0.16 accumulates them with an unchecked `+=` (`client/verify.rs:153`), and those amounts arrive
+  in a caller-supplied skeleton, so an unsummable total panicked in a debug build and wrapped in a
+  release build — after which the wrapped figure was what value conservation was checked against.
+- **wallet:** Charge the rolling period cap the spend's real value, and merge the cap's two
+  overflow checks into the one that is reachable.
+
+### Tests
+- The #1698 exploit is now UNWRITABLE rather than merely rejected: compile-fail proofs for the
+  exploit itself, for minting an approval outside the crate, and for using either token twice,
+  plus trait-absence assertions (`Clone`/`Serialize`/`DeserializeOwned`/`Debug`) and structural
+  invariants (one minter, one field-assembly site, one `derive_summary` call site, no signing
+  function over `&[CoinSpend]`).
+
 ## [0.1.2] - 2026-07-27
 
 ### Features

README.md

@@ -11,16 +11,25 @@ This crate owns the object model, unlock policy + keystore crypto, the in-proces
 signer, per-profile key/DEK derivation, the DID+dig-store mint, and all wallet ops. It never draws
 UI — the host harness (dig-app) injects a UI/auth provider that this crate calls back through.
 
-`PolicyAuthorizer` is the custody gate a host puts in front of signing. It enforces the two-tier
-custody policy and the user's auto-send policy: a vault-tier spend always requires a full
-authorization ceremony and may only ever pay the profile's own hot wallet (via `VaultMove`, a
-24-hour clawback the user can cancel); a hot-wallet spend auto-signs only within its op class, its
-per-transaction limit, and a rolling period cap. Every default refuses.
-
-**The gate is something a host must USE, not something this crate applies for you.** dig-account
-does not compose a send path: the money signer is reachable without the gate, and nothing binds an
-authorization to the coin spends that get signed. `SPEC.md` §6.1.1 states the obligations a host
-takes on, and exactly which of them this crate can and cannot check.
+`PolicyAuthorizer` is the custody gate, and **it is not optional.** It enforces the two-tier custody
+policy and the user's auto-send policy: a vault-tier spend always requires a full authorization
+ceremony and may only ever pay the profile's own hot wallet (via `VaultMove`, a 24-hour clawback the
+user can cancel); a hot-wallet spend auto-signs only within its op class, its per-transaction limit,
+and a rolling period cap. Every default refuses.
+
+**The gate cannot be bypassed, and the thing it approved is the thing that gets signed.** You hand
+`authorize_op` the coin spends — never a description of them — and it derives the summary itself. What
+it returns is a `SpendApproval` that *owns those exact coin spends*, and `sign_approved` is the only
+signing entry point in the crate. So there is no unauthorized route to a signature, and nothing to
+compare that could compare the wrong bytes. Single-use, unmintable outside the gate, and unclonable —
+each held by the type system rather than by a runtime check.
+
+The ruling has three outcomes, not two: approved, **requires confirmation** (run the ceremony, then
+`confirmed`), or refused. That third state is why a spend needing a human reaches the human instead of
+being silently declined.
+
+`SPEC.md` §6.2 is the normative statement, including the limits this layer still does NOT provide
+(§6.1.1).
 
 See [`SPEC.md`](./SPEC.md) for the normative contract. Consumed by `dig-app`.