Follow-up to the initial CS-11156 PR. The publish-realm handler had to
call two methods in sequence to fully invalidate the publishing
replica's cache plus all peers' caches:

    mountedRealmForCacheClear.clearLocalCaches();
    await mountedRealmForCacheClear.notifyAllFileChanges();

Every future emitter would have to remember both lines. Mirroring
`CachingDefinitionLookup.clearRealmCache(url)` — which bundles local
generation bump + DB DELETE + cross-instance NOTIFY in one method —
introduce `Realm.clearLocalCachesAndBroadcast()` that does both steps
and let the handler make one call.

Also drop `Realm.notifyAllFileChanges()`. It was a thin wrapper around
the standalone free function `notifyAllFileChanges(dbAdapter, url)` and
they were used inconsistently — publish used the method, unpublish
used the free function despite having a Realm instance in scope. The
two surfaces collapse to one clear rule:

  - Need local clear AND broadcast (publish handler, realm staying up):
    `realm.clearLocalCachesAndBroadcast()`.
  - Need ONLY the peer broadcast (unpublish/delete handlers, realm
    being torn down — local cache is about to be GC'd with the Realm
    instance): `notifyAllFileChanges(dbAdapter, url)`.

`Realm.clearLocalCaches()` stays as the local-only primitive the
LISTEN handler calls on receive (no broadcast, no NOTIFY loop). The
free function `notifyAllFileChanges` is the single cross-replica emit
surface — the Realm class no longer needs to know about channel names
or payload formats.

No behavior change. All 16 realm-file-changes-listener tests still
pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The publish-realm handler had a hand-rolled `DELETE FROM modules WHERE
resolved_realm_url = $1` to drop stale error entries before the reindex
fan-out. That covers the DB rows but is strictly weaker than
`CachingDefinitionLookup.clearRealmCache(url)`, which:

  1. bumps the per-realm generation counter so in-flight prerenders
     on this replica that started before the DELETE see a mismatch at
     persist time and discard their result instead of re-inserting a
     row this invalidation just removed,
  2. drops in-flight prerender promises for the realm so new callers
     install their own pending against post-swap state rather than
     joining a stale shared transpile,
  3. runs the same DELETE, and
  4. broadcasts on `module_cache_invalidated` so peer realm-server
     replicas perform 1-3 on their own state.

The raw DELETE did only step 3. The reindex worker's prerender fan-out
fires immediately after this code path through HTTP into both this
realm-server and its peers, so missing steps 1, 2, and 4 was exactly
the modules-cache analog of the byte-cache staleness this PR fixes via
`clearLocalCachesAndBroadcast()`.

`clearRealmCache` already runs via the post-fullIndex completion path
in `Realm.startReindex` (realm.ts:1068), but that's at the *end* of
the reindex — too late for the prerender fan-out at the start. Running
it pre-reindex ensures the rebuild starts against a coherent cache on
every replica.

`definitionLookup` is already plumbed through `CreateRoutesArgs`; the
handler just needed to destructure it.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Two completely different caches were both called "the module cache" in
this codebase:
  - `Realm.#moduleCache` — in-process bytes of transpiled JS (the
    prerender's input)
  - `CachingDefinitionLookup`'s `modules` DB table — assembled card
    definitions (the prerender's output)

Both even had a type named `ModuleCacheEntry` with different shapes. The
juxtaposition in `handle-publish-realm.ts` after #4842
(`definitionLookup.clearRealmCache(url)` next to
`realm.clearLocalCachesAndBroadcast()`) made the collision impossible
to ignore.

This commit renames the Realm-side cache to make the "transpiled JS
bytes" framing explicit at the API surface, and renames the public
cache-wipe methods so each call site self-documents which cache it
touches.

  - `Realm.#moduleCache` → `Realm.#transpiledModuleCache`
  - Type `ModuleCacheEntry` (in `realm.ts`, local to that file) →
    `TranspiledModuleEntry`
  - `Realm.clearLocalCaches()` → `Realm.clearLocalSourceCaches()`
  - `Realm.clearLocalCachesAndBroadcast()` →
    `Realm.clearLocalSourceCachesAndBroadcast()`
  - Internal helpers renamed consistently
    (`#dropModuleCacheEntry`, `#bumpModuleCacheGeneration`, the
    generation maps, etc.)

Mechanical rename — no behavior change. 16/16 listener tests pass.
Tier 2 (DefinitionLookup-side renames: `ModuleCacheEntry` →
`DefinitionCacheEntry`, `clearRealmCache` → `clearRealmDefinitions`,
`clearAllModules` → `clearAllDefinitions`, etc.) is a separate
follow-up commit. Tier 3 (DB column + NOTIFY channel rename, needs a
deploy plan for rolling-update compatibility) is deliberately deferred.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

`CachingDefinitionLookup` caches assembled card *definitions* (per-export
results, error entries, dependency lists). It's not a module-byte cache.
But every public type and method on it was named "module cache" or
"modules" — which collided directly with `Realm.#transpiledModuleCache`
(renamed last commit), the actual JS-bytes cache.

Public API now reads as what it does:
  - `ModuleCacheEntry`      → `DefinitionCacheEntry`
  - `ModuleCacheEntries`    → `DefinitionCacheEntries`
  - `ModuleCacheEntryQuery` → `DefinitionCacheEntryQuery`
  - `getModuleCacheEntry`   → `getCachedDefinitions`
  - `getModuleCacheEntries` → `getCachedDefinitionsBatch`
  - `clearAllModules`       → `clearAllDefinitions`
  - `clearRealmCache`       → `clearRealmDefinitions`

Plus internal-consistency renames on the notify-emitter helpers
(`notifyModuleCacheInvalidations` → `notifyDefinitionCacheInvalidations`,
etc.).

What deliberately did NOT move (Tier 3, deferred — needs a deploy
plan for rolling-update compatibility between replicas listening on
the old vs. new channel name):
  - `modules` DB table name and the `MODULES_TABLE` JS constant
  - `module_cache_invalidated` NOTIFY channel name and the
    `MODULE_CACHE_INVALIDATED_CHANNEL` constant
  - File names containing "module-cache-*"

All 16 realm-file-changes-listener tests, 21 module-cache-invalidation-
listener tests, and 9 module-cache-coordination tests pass after the
rename. `tsc` clean across runtime-common / realm-server / host.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>