Record onboarding harness + Stage 1 result; scope Stage 2

Current state: the onboarding doc-harness and its Stage 1 completed-clean
result. ROADMAP: spell out Stage 2 (regtest buyer-pays) under the
agent-payment-connect item. Drop the resolved GET /v1/admin/products 405
debt item.

ROADMAP.md

@@ -16,8 +16,18 @@ Longer-term backlog. Near-term state lives in `AGENTS.md` → Current state.
   (never bundled into `merchant-onboard`), gated by a daemon-level **sandbox-mode flag** as the
   outer gate (production daemons reject scoped connect entirely) with a **network gate** inner
   defense (regtest/testnet/signet only, fail-closed to mainnet). BTCPay network is derived from
-  an on-chain address prefix (no `server/info` field exists). Feeds the doc-harness Path 2
-  (regtest buyer-pays). Ships after doc-harness Path 1.
+  an on-chain address prefix (no `server/info` field exists).
+- **Onboarding doc-harness — Stage 2 (Path 2, regtest buyer-pays).** Gated on slices 3–5 above.
+  Stage 1 (Path 1, no payments) shipped `completed-clean` this session — harness at
+  `licensing-service-startos/onboarding-harness/`, record in its `STAGE1-RESULT.md`. Stage 2
+  reuses the harness but boots the fixture with `KEYSAT_SANDBOX_MODE` on, stands up a Dockerized
+  BTCPay regtest stack (bitcoind regtest + NBXplorer + Postgres + BTCPay) as additional
+  disposable infra, and grants the agent `merchant-onboard` + `payment_providers:write`. Goal:
+  the agent connects BTCPay (regtest) over the API and drives a test buyer payment that activates
+  a license, with zero master-key steps. The walkthrough must be explicitly labeled
+  regtest/test-network and must state that connecting a real mainnet wallet is the one
+  operator-reserved step **by design** (a key that can redirect funds stays with the human) — a
+  security feature, not a gap.
 
 ## Packaging & distribution