fix(cli): wheels packages list — wheels.SemVer dotted path doesn't resolve #2322

Summary

After #2309 fixed the `cli.lucli.services.packages.PackagesMainCli` resolution, `wheels packages list` still fails on a follow-on dotted-path issue: the packages service references `wheels.SemVer` which doesn't resolve when the module is mounted outside a filesystem rooted at `wheels/`.

Repro

Surfaced by `tools/test-onboarding.sh` Phase 7 against a symlink-mounted module:

```
$ wheels packages list
❌ Error: lucee.runtime.exp.ApplicationException: could not find component or class with name [wheels.SemVer]
```

Diagnosis

Same shape as #2309: the codebase has hard-coded absolute dotted paths that assume the module loads under a specific filesystem layout. #2309 fixed `cli.lucli.services.` references; this one is `wheels.` references inside the packages service.

```
$ grep -rn 'createObject.*"wheels\.' cli/lucli/services/packages/
$ grep -rn 'new wheels\.' cli/lucli/services/packages/
$ grep -rn 'extends="wheels\.' cli/lucli/services/packages/
```

(Whichever of these turns up the SemVer reference is the culprit.)

Fix shape

Mirror #2309 — swap absolute `wheels.*` dotted paths for relative paths within the module (`./SemVer` or whatever its actual location is), or register a Lucee mapping at module init that points `/wheels` at the right directory.

Blast radius

Only `wheels packages list` and any downstream subcommands that import SemVer. Doesn't affect the rest of the CLI surface.

Source

Surfaced by the test-onboarding.sh harness running on develop after the dotted-path-trigger fix landed (#2309). Earlier fresh-VM runs hit #2309 first and never reached this layer.