[squad] MINOR findings on PR #4129 (bytecode self-heal seams)

Squad MINOR findings from the review of PR: https://github.com/spec-kitty/spec-kitty/pull/4129 (head d5eea57b943ef5729c990d7a8f4e1a8b7847af0d).

The checklist below references code that does not exist on `main` until that PR merges.

- [ ] src/specify_cli/cli/commands/upgrade.py:1490 — the `from specify_cli.bytecode_heal import invoke_with_bytecode_heal` sits outside the guarded operation, so when `bytecode_heal`'s own `.pyc` is the corrupt file, `spec-kitty upgrade` still dies with the raw traceback — the seam the PR adds is not itself protected there, unlike `main()`'s `_load_bytecode_heal_invoker`, which deletes its own cache file and retries (the planner seam at least degrades loudly via `_ensure_registry_loaded`'s catch). Route this seam through a shared self-healing loader, or wrap the import with the same delete-own-cache-and-retry.
- [ ] src/specify_cli/bytecode_heal.py:94 — the frozen-frame + package-frame heuristic also matches a genuinely missing third-party dependency (`ModuleNotFoundError: No module named 'foo'` raised from a package module's own import statement), so the CLI purges every `.pyc` under the package and retries once before surfacing the real error — harmless (purge is safe, the real error still propagates) but wasteful and confusing in logs. Let a `ModuleNotFoundError` whose `.name` is outside the `specify_cli` namespace propagate unhealed.

Review PR #4129 first, then inspect src/specify_cli/cli/commands/upgrade.py around line 1490 and src/specify_cli/bytecode_heal.py around line 94. Exercise the upgrade bytecode-healing paths and verify that corruption at the import seam and a missing external dependency produce the intended behavior without misleading retries or raw tracebacks.

Written by the indexing model from the issue text.