#3487 bundle freshness: a one-off deno info failure leaves a source on the in-directory fallback for good

Follow-up to swamp-club#3385 (PR swamp-club/swamp#3128), from its adversarial review.

Problem

When ExtensionLoader.bundleWithCache bundles a local source successfully but the deno info module graph read fails (timeout, killed process, abort under load), recordSourceModules records the resolveLocalImports walk bounded at the kind directory instead. From then on the source has a recorded list, so scanCatalogFreshness never treats it as unrecorded again and the graph is never re-read. A model in extensions/models importing ../lib/msg.ts then goes back to the #3385 behaviour: edits to msg.ts do not rebuild the bundle, until a file the walk reaches changes.

Expected

A transient graph-read failure is retried. Retrying on every scan would loop when deno info fails deterministically, so the retry must be bounded. Suggested approach: mark a fallback list recorded after a successful bundle as graph pending, treat it as stale once on the next scan, and record the fallback for good if the retry also fails.

Smaller items from the same review

• recordSourceModules on the success path is not guarded: a catalog write error after a good bundle surfaces as a bundle failure. The failure path already catches and logs at debug.
• findSourceModules rejects lists over 10,000 modules, but recordSourceModules stores them, so such a source is rebundled on every command. Apply the cap on write too.
• rebundleAndUpdateCatalog returns early when the source no longer matches the adapter's export regex, before bundleWithCache, so a source the heal marks stale is never recorded and is re-checked on every command (cheap, but it never settles).
• design/primitives/extensions.md says pulled sources stay on the fallback; a pulled source that rebundles locally does get its graph recorded. Reword to: pulled sources with no recorded list are not forced stale.