FORGE-EVAL-1: subcommand discovery — route forge-* binaries as subcommands

[initializ-mk]

Context

Cross-repo eval epic: the eval product ships a `forge-eval` CLI binary. To keep developer muscle memory unified (devs already use `forge`), Forge should adopt the kubectl-style subcommand discovery pattern: any `forge-*` binary on PATH becomes a `forge *` subcommand.

Scope

In `forge-cli`, when the first positional argument isn't a known built-in subcommand:

1. Look up `forge-` on PATH
2. If found, exec it with the remaining args
3. If not found, fall back to current "unknown command" error

Standard pattern:

```bash
$ forge eval init # routes to /usr/local/bin/forge-eval init
$ forge unknown-foo # "unknown command 'unknown-foo'"
```

Tab completion can be extended to discover `forge-*` binaries and offer them as completion candidates.

Reference implementations

• kubectl: https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/
• git: every `git-foo` binary becomes `git foo`
• gh: explicit `gh extension install` model (heavier — don't copy this one)

We want the git/kubectl model: zero registration, PATH-driven.

Out of scope

• A plugin registry / install mechanism
• Sandboxing or permission-scoping plugins (they run with Forge's perms by design)

Test plan

• Place a script `forge-test-plugin` on PATH that prints its args; `forge test-plugin hello world` runs it and prints `hello world`
• Built-in subcommand (`forge run`, `forge package`) is not overridden by a same-named external binary
• Tab completion (where it exists today) lists external `forge-*` binaries

Dependencies

None. Independent enabling work for FORGE-EVAL-2 and EVAL-14 (CLI).

Cross-repo refs: initializ/eval#14 (the consumer — `forge-eval` binary).