Demo Data Check fails nightly: all three demo wallets 404 on Horizon

[blockchain-maxis]

The scheduled Demo Data Check workflow now fails on every run, and will keep failing until the demo personas are backed by accounts that exist.

This is not a regression — the accounts have never resolved. What changed is that the failure is now visible. Two things landed that surfaced it:

• ci: docs job for link check and stale-reference guard #145 added the docs/CI drift guards, raising the bar for "the pipeline should catch this, not a contributor".
• fix(indexer): single source for demo profile addresses #138 replaced apps/web/public/data/profiles.json with DEMO_PROFILES in packages/types. scripts/check-demo-wallets.mjs read the deleted file, so it was repointed at DEMO_PROFILES — and once it could actually read the personas again, it reported all three as dead.

Reproduce

$ node --experimental-strip-types scripts/check-demo-wallets.mjs
Checking 3 demo wallet(s) against https://horizon-testnet.stellar.org

✗ aquawolf (GASAAEJC6P5UZGRLYJ2I2KYLR7RXGF44JZXDYGCFBN7T5VIHECUUEMCD): 404 — demo wallet no longer resolves on Horizon
✗ sorobuilder (GBVBJEP2BSKHW6YBFCZR2HJKHZDLJOU7ZKTH2HSNUUQY322RWLURH3EQ): 404 — demo wallet no longer resolves on Horizon
✗ stellardev (GBNOH2NKPHZYOWF2LHLSZ27R54NMCH66KPBEEY6MCE4FM5V6PNZVHZKL): 404 — demo wallet no longer resolves on Horizon

3 demo wallet(s) failed to resolve on https://horizon-testnet.stellar.org.

Confirmed directly against Horizon as well — GET /accounts/{wallet} returns 404 for all three.

The indexer sees the same thing whenever it runs against these wallets:

{"lvl":"info","msg":"horizon: account not found","wallet":"GASAAEJC…EMCD",
 "url":"https://horizon-testnet.stellar.org/accounts/GASAAEJC…EMCD/operations?…"}

Why this needs its own issue

The underlying data problem is #56 — generating the demo profiles from real testnet activity, which is the actual fix. This issue is narrower: a scheduled workflow that is red on every run trains everyone to ignore it. That has to be resolved one way or another before #56 lands, and the two have different resolutions.

demo-data-check.yml deliberately never runs on pull_request, so this cannot block a merge — but it also means nobody sees it unless they open the Actions tab.

Options

1. Fix the data (preferred, = 🔒 Generate the demo profiles from real testnet activity #56). Generate and fund real testnet keypairs, submit real operations, dump their genuine Horizon output. The guard then passes for the right reason, and the explorer links stop being dead.
2. Make the guard advisory until then. Have it report without failing, or pin it to a known-empty expectation, so a red run means "something changed" rather than "still the same three".
3. Narrow what it asserts. Check that each persona's wallet is well-formed and that the fixture source_account matches, and only assert Horizon resolution once the accounts are real.

Option 1 is the only one that makes the demo profiles honest; 2 and 3 are holding patterns that stop the signal decaying in the meantime.

Acceptance

Either the three personas resolve on horizon-testnet.stellar.org and the nightly run is green, or the guard's failure condition is redefined so that a red run means a genuine change rather than a known, unfixed state.

Related: #56 (root cause and real fix), #57 (the single-source refactor that surfaced this), #135 (the CI drift-guard work).