#2570 extensions: cold start re-warns type extraction when the repo is reached under a different path spelling

Found during live verification of swamp-club#2562 (swamp-club/swamp#2646). This is cosmetic: winners and the final catalog are correct.

Summary

When a repo is reached under a different spelling of its root from the one that wrote the extension catalog (on macOS, /tmp/r vs /private/tmp/r), the first command or swamp serve start prints one false "type could not be read statically from the export block" warning for each extension whose export wraps its definition. @swamp/gcp-organization has 20 such files, e.g. export const extension = withGcpVerbosity(definition).

Since #2646, a cold rebuild keeps rows that the import-based reconcile already indexed, so these warnings no longer appear when the spelling is consistent. Before #2646 they appeared on every cold start.

Reproduction

1. swamp repo init /tmp/r, then cd /tmp/r (the cwd resolves to /private/tmp/r) and run swamp extension pull @swamp/gcp-organization.
2. Run any command from that directory, so the catalog rows are written under /private/tmp/r.
3. Run swamp serve --repo-dir /tmp/r, or any command with --repo-dir /tmp/r.
4. On startup, stderr shows 20 swamp-warning: /tmp/r/.swamp/pulled-extensions/@swamp/gcp-organization/...: type could not be read statically ... lines. The next start is quiet.

Cause

The source-dirs fingerprint changes with the spelling, which invalidates the catalog and forces a cold buildIndex. ExtensionLoader.populateCatalogFromDir looks up each file with catalog.findBySourcePath under the new spelling. That misses the rows written under the old one, so it falls back to static extractTypeFromSource, which cannot read wrapped exports. The rows are later rewritten under the new spelling, and the warnings stop.

Possible fix

On a miss, retry the lookup with the symlink-resolved path. The extension loader's contributorFor already resolves symlinks for identity. Check how this interacts with the pruning of rows outside the repo root, so wrapped extensions are not left without a row for that run.

Expected

A repo reached under a second spelling of the same root should not warn about extensions that are already indexed.