eCash: 2 of 10 missions have a hands-on step

[Jolah1]

Part of #76.

Two hands-on missions out of ten (33 ecash-claim, 34 ecash-spend). The remaining eight cover blind signatures, mint trust models, Cashu vs Fedimint, multi-mint wallets and failure modes, all as reading.

Proposals

Mission 84 (what a token actually looks like) is the obvious one, and it is currently a missed layup: the learner already holds a token from mission 33, and the lesson describes its anatomy without ever asking them to open it. Decode a cashuA... token client-side and report the mint URL, amount and proof count. Base64 and JSON, no network needed.

Mission 85 (multi-mint wallets) — claim from a second mint and hold balances at two, so "your balance is per mint, not global" is something they saw rather than read.

Mission 86 (when mints fail) — attempt to redeem an already-spent token and observe the exact error. Honest failure modes are the path's stated theme, and this one is safe to trigger on purpose.

Mission 57 (mint trust: 1-of-N vs federation) — look up a real mint's published info endpoint and report who runs it and what it discloses. Reinforces "small, replaceable, audit-it-yourself" from mission 32.

Notes

• eCash runs against a real Cashu mint when reachable and simulates otherwise, reported by /api/runtime. New steps should degrade the same way.
• Token decoding is client-side, so mission 84 needs no backend at all and is the easiest place to start.
• Content in frontend/src/lib/types.ts. See Curriculum: 91 of 106 missions end at a quiz #76. One mission is a fine PR.

[Jolah1]

Heads-up before anyone starts mission 84 (the "decode the token" layup): the token mission 33 hands the learner is not decodable, so the obvious version of this task is blocked today.

The eCash service is a stub, not a "real when reachable" integration. In backend/src/services/ecash_service.rs:

• simulated is hardcoded true (EcashService::new), so nothing ever connects to a mint. The note in this issue saying it "runs against a real Cashu mint when reachable" is stale.
• mint_token emits format!("cashuBsim_{ts}_{amount}") — a cashuB-prefixed string, not base64url-CBOR. There is no mint URL, amount, or proof list encoded in it, so "decode it and report mint/amount/proof count" has nothing to read.

Why it's a stub (not laziness): the real CDK integration was removed when we moved sqlx to 0.8.6 to clear 5 RustSec advisories. cdk-sqlite 0.16 pins libsqlite3-sys 0.28 (via rusqlite 0.31), and Cargo's links rule forbids linking the same native lib at two versions in one binary. It comes back when cdk ships a release compatible with libsqlite3-sys 0.30.

So a contributor has two honest paths for mission 84:

1. Self-contained (recommended, unblocked now): decode a bundled real cashuA.../cashuB... sample token shipped as fixture content in the lesson, independent of what mission 33 produced. Pure client-side base64+JSON/CBOR, no backend, teaches the anatomy exactly as intended, and stays honest because it doesn't pretend the sim token is real.
2. Wait for the CDK restore, then decode the learner's own token from mission 33. Blocked on the dependency above.

If you take path 1, don't wire the decode step to the participant's stored mission-33 proof — it's cashuBsim_... and will fail to parse.