wheels new: explicit WHEELS_FRAMEWORK_PATH should hard-fail when it doesn't exist

[bpamiri]

Follow-up noticed while working on #2211.

Current behavior

In cli/lucli/Module.cfc:3454-3469 (resolveFrameworkSource), when the user explicitly sets `WHEELS_FRAMEWORK_PATH`:

```cfm
var override = javaSystem.getenv("WHEELS_FRAMEWORK_PATH");
if (!isNull(override) && len(trim(override))) {
arrayAppend(variables.frameworkSearchPaths, override & " (from $WHEELS_FRAMEWORK_PATH)");
if (directoryExists(override)) {
return override;
}
}
```

If the path exists, it's used. If it doesn't exist, the code silently falls through to the next search path (project root → module root walk). The user's explicit instruction is ignored with no warning.

Why that's wrong

If I explicitly set `WHEELS_FRAMEWORK_PATH=/some/path`, I'm telling the CLI "use this, not something else." A typo or a stale path should be flagged — not silently overridden by whatever happens to be discoverable elsewhere. The current fallback can produce surprising results where one developer gets a different framework version than they expected.

Proposed fix

When `WHEELS_FRAMEWORK_PATH` is set but `directoryExists()` is false, throw early:

```
Error: WHEELS_FRAMEWORK_PATH is set to '/some/path' but that directory does not exist.
Unset the variable to fall back to auto-discovery, or point it at a valid vendor/wheels/ source.
```

Exit non-zero (same mechanism as #2211).

Acceptance

• `WHEELS_FRAMEWORK_PATH=/does/not/exist wheels new foo` exits non-zero with a clear message
• Unsetting the variable restores the auto-discovery fallback behavior
• `WHEELS_FRAMEWORK_PATH=/valid/path wheels new foo` still works

Related

• wheels new exits 0 when framework-not-found, masks fatal errors to automation #2211 — the exit-code fix that made this discoverable