Consider timing diagnostics and adapters for slow repeated CLI startup

Some CLI golden suites run the same command many times, and for TypeScript/Node CLIs a
single cold start can be around a second. When a tryscript file or suite has many console
blocks, that startup cost can dominate the run even when tryscript's own matching overhead
is small.

It would be useful to consider support or guidance here without changing tryscript's core
shell semantics.

Possible directions:

- Document how to diagnose startup-bound suites versus output-matching overhead.
- Add optional timing diagnostics, such as per-command duration and a slowest-commands
summary.
- Provide guidance for CLI authors on reducing startup cost: lazy imports, prebuilt JS,
Node compile cache, avoiding heavy barrel imports, etc.
- Consider an advanced adapter/lifecycle pattern for CLIs that can safely run multiple
invocations through one prestarted process while preserving argv, cwd, env, stdin,
stdout/stderr, and exit-code behavior.

The adapter idea is not universally safe because many CLIs rely on process isolation or
global state. Even if tryscript does not implement daemonization directly, docs and timing
visibility would help users see where slow golden tests are spending time and choose the
right mitigation.

issue にはファイルもテストも記載されていません。まず、コマンドを繰り返し実行する suite を再現し、起動時間と出力マッチングのオーバーヘッドを比較します。次に、方向性を 1 つ—タイミング診断、ドキュメント、または adapter—に絞り込みます。完了時には、明確なガイダンスまたは診断に加えて、任意の adapter について argv、cwd、環境、streams、exit-code の動作が維持されている必要があります。

索引モデルが issue の本文から書いたものです。