Concern about aliasing strategy in Vite-Plus

### Description

This follows from https://github.com/voidzero-dev/vite-plus/issues/1557 and the related Oxc discussion in https://github.com/oxc-project/oxc/issues/22539.

After looking through the current Vite+ codebase, I think my concern is more specific than "Vite+ ships special versions of everything".

The current setup has several different integration models at once:

- `vite` is resolved through the `@voidzero-dev/vite-plus-core` alias.
- Vite/Rolldown/tsdown are bundled/re-exported through `@voidzero-dev/vite-plus-core`.
- `vitest` no longer uses the old `@voidzero-dev/vite-plus-test` wrapper, but Vite+ still exposes and migrates imports to `vite-plus/test*`, with runner/version pinning to keep a single Vitest instance.
- `oxlint` and `oxfmt` are upstream dependencies, but Vite+ still exposes canonical `oxlint` / `oxfmt` bin names as IDE/LSP wrappers that inject Vite+ config-loading behavior.

Each individual piece has a reason, but together this creates an unclear contract for users and integrations: when should a tool continue looking for the canonical package/bin/import (`vite`, `vitest`, `oxlint`, `oxfmt`), and when should it know about `vite-plus`, `vite-plus/test*`, or `vp`?

That is the part that feels fragile. Package managers, editor extensions, LSP launchers, and user code all tend to assume canonical tool identities. When Vite+ needs wrappers, aliases, generated shims, and package-manager-specific edges, every integration can end up rediscovering the same special cases.

### Suggested solution

What I suggested in the oxc issue.

- Keep `vp` as the unified command surface.
- Keep `vite.config.ts` as the place where Vite+ can unify config for lint, format, test, build, pack, etc.
- Let the individual tools use `vite.config.ts` when is available as well.
- Treat Vite+ as the orchestrating layer over those tools, not as something that every tool identity has to be rewritten into.

### Additional context

The specific thing I would like to avoid is Vite+ adoption requiring users and integrations to know a growing list of package identity rules.

As a user, I don't want to worry about having to maintain Vite+ wrappers, alias, or shim and how they get updated in tandem with the base tools that I already use.

### Validations

- [x] Read the [Contributing Guidelines](https://github.com/voidzero-dev/vite-plus/blob/main/CONTRIBUTING.md).
- [x] Confirm this request is for Vite+ itself and not for Vite, Vitest, tsdown, Rolldown, or Oxc.
- [x] Check that there isn't already an issue requesting the same feature.

Start with vite.config.ts and the vp command surface, then trace the existing aliases, wrappers, generated shims, and canonical package or bin identities described in the issue. Done would require an agreed integration contract that reduces special cases for package managers, editors, LSP launchers, and user code; the issue does not identify concrete files or tests.

Escrito por el modelo de indexación a partir del texto del issue.