Marketplace listing invisible to `market get`/`market list` for 4+ min after successful `market publish`, despite live storefront page

Reproduction steps:

1. Have a signed, valid RailCall v2 module (manifest verified locally and by

railcall market module verify), with a category from the accepted enum.

1. Run railcall market publish <module-dir>. Response: "Module published."

with id: <publisher>/<module> and "Live at:
https://railcall.ai/marketplace/<publisher>/<module>".

1. Immediately fetch the storefront URL from that response. It resolves

HTTP 200 with the real listing rendered (correct title, publisher name,
category).

1. Run railcall market get <publisher>/<module>. Result: "Unknown listing:

<publisher>/<module>" (HTTP 404 from /v1/market/get).

1. Run railcall market list --all. Result: "No listings matched." (empty

result from /v1/market/list).

1. Repeat steps 4-5 at 30-second intervals. Exact timestamps from this run

(all UTC):
- Published, then immediate check: 404.
- Retry after ~20s: still 404.
- Spaced poll, 30s apart: 22:25:36, 22:26:08, 22:26:39, 22:27:12,
22:27:43, 22:28:16 — all six return "Unknown listing."
- Final market list --all at the same time as the last poll: still
"No listings matched."
- Total elapsed from publish to last check: on the order of several
minutes, with zero change in outcome.

Expected: A listing that renders correctly on the public storefront page
should resolve the same way through market get/list within at most a few
seconds — these are presented as the same catalog to the user (the storefront
page even tells buyers to run "railcall market install <id>").

Actual: The storefront page (railcall.ai/marketplace/...) and the CLI's
catalog API (/v1/market/get, /v1/market/list) disagree for a sustained period
(4+ minutes observed, not just propagation-lag-scale seconds). The storefront
has the listing; the catalog API used by get/list/presumably install does not.

Root cause (best-effort, from tracing railcall_cli.py, not backend access):
market publish POSTs to /listings. The storefront page apparently reads from
that same write path directly (it renders correctly seconds after publish).
market get/market list instead query /v1/market/get and /v1/market/list — a
different API surface, most likely backed by a separate index, cache, or
search store that isn't updated synchronously (or isn't updated at all in a
timely way) when a new listing lands via /listings. Can't confirm the exact
backend mechanism, but the two-different-endpoint-families pattern in the
CLI source is consistent with a sync/indexing gap between the write path and
the catalog read path, rather than a client-side bug (both get and list used
--all/no filters, ruling out a filter/pagination miss).

Suggested fix (if applicable): Either (a) have the catalog index update
synchronously (or near-synchronously) as part of the same publish transaction
that makes the listing visible on the storefront, or (b) if indexing is
genuinely asynchronous, have the storefront page reflect a "pending index"
state instead of rendering a fully-live listing page before the module is
actually installable — so the two surfaces never disagree about whether a
listing is real/ready.

Impact: Any publisher who publishes a new module gets a storefront page and
a "Live at" URL that looks fully successful, but buyers (or the publisher
themselves) following the storefront's own displayed instruction (railcall
market install <id>) will hit "Unknown listing" for an unknown-but-non-trivial
window afterward. This is a trust/usability gap on every fresh publish, not
specific to this module.