feat(openspec): bootstrap behavioral specifications for various product domains

[Parsh]

Summary

This PR introduces the complete OpenSpec baseline for Bitcoin Keeper, 17 behavioral
specification files that collectively describe what the app currently does, written as
observable, implementation-agnostic requirements and Given/When/Then scenarios.

These specs document the system as it exists today. Every future change to the app will
be expressed as a delta on top of this baseline, making the specs the durable source of
truth for product behavior.

---

What's included

Each file lives at openspec/specs/<domain>/spec.md and follows the canonical template
defined in the bootstrap plan.

• authentication — App unlock, PIN setup, biometric fallback, deep link handling
• wallets — Single-sig wallet creation, import, sync, visibility, script types
• signing-devices — Hardware, software, and assisted key lifecycle
• vault — Multi-sig creation, quorum policy, Miniscript types, migration, archiving
• send-and-receive — PSBT lifecycle, multi-device signing, broadcast, receive addresses
• transaction-history — Transaction list, detail view, labels, caching, unconfirmed state
• utxo-management — Coin control, UTXO labeling/freezing, manual selection, label import/export
• backup-and-recovery — Seed backup/confirmation, cloud backup, app image recovery, relay sync
• health-checks — Signer health check flows, status tracking, UAI prompts
• inheritance — Timelocked vaults, emergency/reserve keys, timelock reset, PDF export
• collaborative-wallet — Multi-party key exchange, coordinator session, vault completion
• subscription — Tier gating, plan display, IAP, receipt verification, discount codes
• settings — Node config, Tor, network switching, currency/units/theme/language
• notifications — FCM registration, UAI stack, dismissal, per-type alert behavior
• concierge — Zendesk-backed support tickets, comments, account manager panel
• buy-bitcoin — Third-party purchase entry point, address pre-fill, WebView flow
• usdt — USDT wallet create/send/receive, history, exchange rates, separation from BTC wallets

---

What these specs are (and aren't)

Are: Observable, user-facing behavior statements using RFC 2119 keywords (MUST/SHOULD/MAY).
Every requirement has at least one happy-path scenario and one failure or edge-case scenario.
Tier-gating requirements explicitly name the minimum subscription tier.

Are not: Architecture decisions, library choices, Redux action names, class structures,
or anything that belongs in a design.md or tasks.md. If you spot implementation detail
in a spec, that's a review finding.

---

Authoring approach

Specs were written in dependency order: authentication first (unblocks everything), then
wallets and signing-devices in parallel, then composite domains after their dependencies
were reviewed.

High-risk domains (send-and-receive, backup-and-recovery, vault) received fuller scenario
coverage. Lower-risk domains (buy-bitcoin, concierge, usdt) are intentionally lightweight.

---

How to review

Focus on behavioral completeness and correctness — not style. For each spec ask:

1. Missing behavior — Is there something the app clearly does that has no requirement here?
2. Wrong modal verb — Is a MUST actually a SHOULD, or vice versa?
3. Implementation leak — Does any scenario mention a class name, Redux action, or internal
   state that a user cannot observe?
4. Tier gating accuracy — Do the subscription tier references match the actual gating logic?
5. Scenario testability — Could a QA engineer write an automated test from each
   Given/When/Then block without additional context?

The ## Non-Goals section of each spec documents known scope boundaries explicitly —
worth a quick read to avoid scope creep in future change proposals.