CLI: known subcommand name passed as option value is treated as subcommand

### Bug description

`parseArgs` (`src/vs/platform/environment/node/argv.ts`) elects the first bare token that names a known subcommand without checking whether that token is the value of a preceding string option. The comment above the `find` claims the value case is handled, but the predicate only checks the token shape, so a subcommand name used as an option value is still elected:

```
code --profile agent
```

`agent` is the value of `--profile`, but since `agent` is also a registered subcommand it wins: the CLI silently discards `--profile` and starts the agent subcommand.

The same collision exists for every string option followed by a token matching `tunnel`, `serve-web`, `chat` or another subcommand name (e.g. a profile literally named `tunnel`).

### Steps to reproduce

1. Run `code --profile agent` with a profile named something else, or trace `parseArgs(['--profile','agent'], options)` directly.
2. The parsed result enters subcommand mode for `agent`; `--profile` never appears in the result.

### Expected behavior

A token preceded by an option that expects a string value is consumed as that value, never as the subcommand; `code --profile agent` selects the profile `agent`.

### Version tested

Commit `38ec3d57f91b` on `main`. A fix is ready that tracks pending option values (including aliases and deprecated ids) while scanning, with unit tests in the existing argv test block.