wheels doctor: detect stale `~/.wheels/modules/wheels/` install that shadows source checkout

[bpamiri]

Follow-up noticed while working on #2215.

Context

wheels and lucli are the same binary renamed. When invoked as wheels, LuCLI reads modules from ~/.wheels/modules/ (not ~/.lucli/modules/). If ~/.wheels/modules/wheels/ is a real directory holding an installed copy of Module.cfc (rather than a symlink to the source checkout), a merged fix in the source repo will not take effect for the wheels CLI on that machine.

This happened locally during #2222: the #2216 fix for framework-not-found exit codes was merged, but wheels kept exit-0ing because ~/.wheels/modules/wheels/Module.cfc was a pre-#2216 copy.

Why this is footgun-class

• Symptoms look like "the fix didn't land" — a contributor debugging a CI-green PR locally gets exit-0 behavior that contradicts the merged code.
• No error is surfaced; the stale module just runs.
• Easy to miss because ~/.wheels/modules/wheels/ has no visible "installed version" marker that tracks repo state.

Proposed check

Add a new category to cli/lucli/services/Doctor.cfc (or a new CLI-scoped sibling):

• Detect whether the user is inside a wheels source checkout (e.g. cwd has cli/lucli/Module.cfc and vendor/wheels/).
• If so, compare the installed module at ~/.wheels/modules/wheels/Module.cfc against the checkout's cli/lucli/Module.cfc:
  • If the installed path is a symlink to the checkout → OK
  • If it's a real file with matching bytes → OK (stale but harmless this moment)
  • If it's a real file with different bytes → warn: "Your installed wheels module at ~/.wheels/modules/wheels/ diverges from your source checkout. CLI changes you make to cli/lucli/ won't take effect until you reinstall or symlink."
• Include the remediation (install/link command) in the warning.

Open questions

• Where does the divergence check live? The existing Doctor service is project-scoped (migrations, config, db). This check is CLI-install-scoped. Options:
  1. New category inside Doctor.cfc — keeps one entry point but muddies the service's purpose.
  2. New wheels doctor --cli subcommand or new wheels install status command — cleaner separation.
• Should wheels modules install wheels (if that's the install path) ever create a symlink automatically when run from inside a source checkout? Would obviate most of this, but could surprise users who want the installed copy pinned.

Related

• wheels new: explicit WHEELS_FRAMEWORK_PATH should hard-fail when it doesn't exist #2215 / fix(cli): hard-fail invalid WHEELS_FRAMEWORK_PATH instead of silent fallback (#2215) #2222 — the fix that surfaced this
• fix(cli): wheels new exits non-zero on framework-not-found (#2211) #2216 — merged fix that was masked locally by the stale install