#318 Investigate whether allExtensionMethodsAttached guard can be removed via registration-path consolidation

Problem

The W5 audit (swamp-club#290) assumed allExtensionMethodsAttached was a cache-aliasing workaround eligible for deletion once per-fingerprint import URLs landed. Git archaeology of commit 9e86b9d1 (fix for swamp-club#123) reveals it serves a different purpose: it's an idempotency guard that prevents ModelRegistry.extend from throwing on duplicate methods when attachPendingExtensionsForType runs.

Two code paths — hotLoadModels after ExtensionAutoResolver installs a missing extension, and rebundleAndUpdateCatalog during buildIndex's stale-files loop — register base models without attaching their catalog-recorded extensions. The guard checks whether all methods/checks are already present before re-importing.

Why it can't be deleted with W5

Per-fingerprint URLs do NOT address this duplicate-registration scenario. The guard is NOT eligible for deletion just because per-fingerprint URLs land. Deleting it would reintroduce swamp-club#123's "Unknown method" errors from detached extensions.

When it becomes removable

If a future workstream consolidates the registration paths so the duplicate-call scenario structurally cannot happen, the guard becomes safely removable. Until then, it remains load-bearing for issue #123-class problems.

Suggested scope

Could fold into W6 (doctor extensions) territory or be its own freestanding tracker. The work would involve:

1. Auditing all code paths that call modelRegistry.register() directly
2. Ensuring each path also attaches catalog-recorded extensions
3. Once no path can register without attaching, the guard is redundant and can be deleted
4. Writing a regression test for the #123 scenario to confirm safe removal