Verify that $readFrameworkVersion()'s default rootBoxJsonPath actually reaches the monorepo at runtime

[bpamiri]

Context

Surfaced while fixing #2279 (PR #2289). That fix is CLI-side — it rewrites the placeholder during wheels new so newly-scaffolded apps no longer show 0.0.0-dev. While tracing the bug I noticed a path computation in the framework-side fallback (from PR #2272, which closed #2255) that may not do what its unit tests suggest.

Suspected defect

In vendor/wheels/Global.cfc, $readFrameworkVersion() computes its default enclosing-repo box.json path as:

local.rootPath = Len(arguments.rootBoxJsonPath)
    ? arguments.rootBoxJsonPath
    : GetDirectoryFromPath(GetCurrentTemplatePath()) & "../box.json";

GetCurrentTemplatePath() inside a method defined in Global.cfc returns the path of Global.cfc itself (…/vendor/wheels/Global.cfc). GetDirectoryFromPath() of that is …/vendor/wheels/. Appending ../box.json gives …/vendor/wheels/../box.json, which the OS resolves to …/vendor/box.json.

But the monorepo layout is:

<repo-root>/
├── box.json                 ← monorepo root (slug=wheels, name=Wheels.fw)
└── vendor/
    └── wheels/
        ├── box.json         ← framework
        └── Global.cfc

To reach the monorepo root from vendor/wheels/, the helper needs to walk up two levels, not one — the correct string would be "../../box.json". As written, it looks for vendor/box.json, which doesn't exist in the monorepo. The monorepo-detect branch therefore can't fire with default args, and $readFrameworkVersion() falls through to "0.0.0-dev" exactly as it did before #2272 — at least for runtime boot via onapplicationstart.cfc, where the helper is called with no arguments.

Why the existing tests didn't catch it

vendor/wheels/tests/specs/events/frameworkVersionSpec.cfc exercises the "synthesizes <rootversion>-dev" branch via explicit path arguments, bypassing the default computation:

expect(g.$readFrameworkVersion(fwTmp, rootTmp)).toBe("4.0.0-dev");

The specs pass because the temp files exist. The default-args path at runtime boot is uncovered. In PR #2272's test plan the "Manual smoke: load / on the wheels-dev/wheels dev server — expect 4.0.0-dev" checkbox is unchecked.

Task

1. Boot the wheels-dev/wheels dev server from a fresh develop checkout and verify what application.wheels.version resolves to. If it's 0.0.0-dev, the concern above is confirmed and Homepage displays incorrect Wheels version (0.0.0-dev) instead of actual version #2255 should be reopened.
2. If confirmed, the fix is one-line: change "../box.json" to "../../box.json" in the default rootBoxJsonPath computation, plus add a spec that verifies the default path resolves correctly (not just the explicit-args path).
3. Keep Homepage still shows 0.0.0-dev in new apps #2279's fix regardless — that one addresses the vendored-copy-in-generated-app case, which is a different code path and won't be helped by fixing the framework-side default.

cc @bpamiri