fix: run gutter tests with the most specific config when several configs claim the same file

[bennycode]

Fixes #799

A shared base config like vitest.config.base.ts matches the extension's configGlob, so it gets its own Vitest instance that claims the same test files as the package-level configs that merge it. The gutter "Run Test" button then runs tests with the base config, which is missing the merged options (tags, env, …):

Error: The Vitest config does't define any "tags", cannot apply "tulipindicators" tag for this test.

Why registration order alone doesn't fix it

@sheremet-va suggested in #799 to register the profiles in a different order so vscode picks up the more specific config automatically. I tried that first and on its own it changes nothing. A file item only gets the tag of the first config that resolves it (getOrCreateFileTestItem returns the cached item without touching its tags), and since profiles are tag-scoped, the shallowest config's profile is the only one VS Code can ever pick for that file, no matter the registration order.

Fix

1. File items collect the tags of every config that claims them. getOrCreateFolderTestItem already does this for folder items. File items were the inconsistency: with two configs claiming the same directory, the folder item is runnable by both configs' profiles, but the files inside it only by the first one.
2. Run/debug/coverage profiles are registered for all discovered configs before any process spawns, deepest config first. When several profiles can run the same item, vscode invokes the first registered one, so the most specific config becomes the effective default. Label and tag come from the config path, so nothing waits for resolution and initialisation isn't delayed (the concern raised in Vitest extension doesn't run test files with tags #799). Config resolution order and workspace config claiming are unchanged; profiles for configs that never resolve are disposed.

The base config's profile stays available in the profile picker; only the effective default changes. Configs at the same depth behave as before.

Tests

Added samples/shared-base-config and an e2e test that clicks the gutter run button. The sample test only passes under the package-level config (it asserts on an env value), so the run result shows which config executed it: 0/1 before this change, 1/1 after.

[bennycode]

Closing because the proposed change only makes all claiming profiles eligible; it does not change which profile VS Code selects by default and therefore does not resolve #799.