fix: support Bitkit local wallet tests

[ben-kaufman]

Summary

• make the Paykit Compose demo work with a Bitkit-authenticated creator instead of importing or generating the creator wallet identity in the demo
• add a loopback-only Homegate bridge and expose Fulcrum so iOS and Android local test builds can sign up and use the regtest wallet backend
• build the Locks WASM package into the demo images so a host-generated package is no longer required
• render guarded text, JSON, images, and binary downloads safely without persisting private response bytes in browser storage

This is intentionally stacked on #10 because it hardens and completes that demo's app-wallet test path.

Contract and risk impact

• Public API or SDK contract
• Persisted data or migration
• Authentication, authorization, identity, or secret handling
• Payment or entitlement behavior
• Runtime, deployment, or observability
• No contract/risk impact

Verification

• npm --prefix examples/js-sdk run check
• npm --prefix examples/js-sdk run validate:paykit-compose
• node examples/js-sdk/scripts/smoke-paykit-compose.mjs
• clean docker compose -f compose.paykit-local-demo.yaml build creator-demo
• Linux image checks: Paykit reader worker, Paykit Compose smoke, and JS SDK examples smoke
• clean Compose startup with the creator host port remapped from occupied 8080 to 18080
• verified every long-running service stayed healthy, reader state was waiting, Homegate returned a valid signup response, creator preflight passed, and Fulcrum answered an Electrum version request

Documentation

Updated examples/js-sdk/README.md for the external-wallet flow, local service endpoints, and runtime reset.

Checklist

• The change is focused and self-reviewed.
• Regression tests were added where practical.
• No credentials, identities, private content, payment material, or generated local state are included.
• Formatting and relevant tests/lints pass.

[ovitrif]

One blocking issue and one non-blocking issue remain:

• Creator-demo boots with --external-wallet and publishes the creator profile only after wallet approval, but reader-demo still binds once from .local/creator-public/profile.json and can run against a stale prior identity or terminal-fail while the profile is missing.
• /api/demo-auth/start still returns a recovery-file authenticate command under --external-wallet, so the creator page can steer operators onto a local recovery identity instead of the Bitkit wallet.

[ben-kaufman]

@jvsena42 could you please review the current head? The external-wallet identity/profile fixes have been exercised in the clean iOS and Android Locks → Paykit → Bitkit E2E flow, and all prior review threads are resolved.

[ben-kaufman]

@jvsena42 follow-up: the current signed head is 1a5f97c and now includes the aligned JS example smoke assertions discovered by CI; the exact smoke suite passes in the Linux demo image.

[ovitrif]

Thanks for addressing the recovery-auth command. One blocking issue remains: the waiting_for_creator gate still waits on the private content-creator profile path, so Compose external-wallet never observes the published creator-public profile and the reader never prepares.

[ovitrif]

The waiting_for_creator gate now reads PAYKIT_READER_CREATOR_PROFILE_PATH, matching the Compose creator-public profile publish path, so the earlier external-wallet reader setup blocker is fixed.

LGTM

[dzdidi]

LGTM, looks like it still working with the non-bitkit tests. May you please confirm? Once confirmed it is merge