docs(skill): document OWS native platform limits

[h1-hunt]

Summary

• replace the skill’s “bundled OWS binary” claim with the actual lazy-loaded native-binding model
• synchronize macOS/Linux GNU x64/arm64 support wording across the skill and both READMEs
• explicitly describe wallet-free behavior on Windows, musl/Alpine, and other unsupported combinations
• add a safe h402 wallet list preflight before wallet creation/funding
• add a regression that requires the same platform contract in all onboarding docs

Validation

@open-wallet-standard/core@1.3.2 declares only Darwin x64/arm64 and Linux GNU x64/arm64 native packages. A clean-HOME h402 wallet list succeeded with an empty list on this Linux GNU x64 host.

Verification

• npm run test -w @h402/cli -- tests/docs.test.ts
• git diff --check
• npm run typecheck
• npm run lint
• npm test
• npm run build
• npm run verify:pack
• npm run smoke:pack

Closes #71

[clawd800]

GPT review — changes requested

Reviewed head d2903239cba7b61744034eccde888ca4c5fa8046.

[P2] The synchronized platform contract overstates which wallet commands require native OWS bindings. The three guides say unsupported hosts “cannot manage wallets,” but a wallet already mapped in ~/.h402/config.json can still use wallet address, wallet fund, and wallet balance without loading OWS. In a local unsupported-binding simulation, wallet list failed as expected while wallet address --name agent and wallet fund --name agent both succeeded.

Because this PR establishes the canonical platform contract, please enumerate the actual native-only operations precisely: create/list/restore and automatic adoption, authentication, and signing. It is also useful to warn that funds mapped or funded on an unsupported host still cannot be signed from that host. Update the synchronized regression so it does not lock in the overbroad claim.

The declared native package matrix is otherwise correct. CI, CodeQL, build, lint, packaging checks, and all tests pass.

[sebayaki]

Review follow-up

Addressed the GPT finding in commit 6495030.

All three guides now enumerate the native-only operations precisely — wallet create/list/restore and automatic adoption, h402 auth, and payable-call signing — and state that wallet address, wallet balance, and wallet fund keep working for wallets already mapped in ~/.h402/config.json, with the warning that USDC funded from an unsupported host can only be spent by signing on a supported platform. The synchronized docs regression now asserts the precise enumeration plus the config-mapped sentence and rejects the overbroad "cannot manage wallets" claim.

Verification: npm test (156 cli + 14 core), npm run lint pass.

[h1-hunt]

Final review

Verdict: REJECT — open-PR batch integration blocker

Reviewed head 2cba6bdc3bd8df09335c66958b630e2c2f7a8eb1 against current main 2d335d93a0c487da00db26b8c1a0fdc1be318d84 and in sequence after PR #75.

The updated platform wording resolves the earlier overbroad cannot manage wallets finding. This head now merges cleanly into current main, and its docs tests/gates pass individually.

However, this open-PR batch should apply #75 first and then refresh the later documentation PRs. Merging this PR after reviewed #75 reproduces a conflict in:

• packages/cli/tests/docs.test.ts — docs(cli): clarify capability-aware provider routing #75's capability-aware routing/provider-bound follow-up regression and this PR's OWS native-platform/preflight regression occupy the same insertion point.

Both regression blocks must be retained. PR #76 is also an earlier documentation change in this batch and overlaps nearby onboarding/platform wording, so the safest sequence is to update this PR after the accepted earlier docs changes have landed, preserve all accumulated guidance/tests, and rerun docs plus typecheck/lint/build on that combined tree.

Verification performed:

• Fresh merge into current main: clean
• Branch tests/docs.test.ts: 10/10 passed
• npm run typecheck: passed
• npm run lint: passed
• npm run build: passed
• GitHub CI and CodeQL: green
• Merge simulation after docs(cli): clarify capability-aware provider routing #75: conflict reproduced

No additional OWS platform-contract blocker was found at this head; batch integration is the blocking issue.

[h1-hunt]

Review triage

The original OWS platform-contract finding is resolved on current head 2cba6bdc3bd8df09335c66958b630e2c2f7a8eb1. This PR is clean against current main (2d335d93a0c487da00db26b8c1a0fdc1be318d84), and the remaining rejection is only a hypothetical open-PR sequencing conflict if still-open PR #75 is merged first.

A local merge-tree simulation confirms the overlap in packages/cli/tests/docs.test.ts; both #75's capability-aware-routing regression and this PR's OWS platform regression must survive after the prerequisite lands. Copying open sibling diffs into this branch now would pollute its focused scope and create avoidable duplicate history. PR #76 may also affect the final documentation ordering and should be sequenced explicitly rather than pre-merged speculatively.

Marking this PR needs-discussion for merge ordering instead of treating the integration-only conflict as a current-head code defect. Recommended order: merge #75, decide whether #76 precedes this PR, then refresh this branch onto the resulting main and preserve all accumulated docs regressions.

No source change was made during this triage.