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.

No file or test is named in the issue. First reproduce a repeated-command suite and compare startup time with output-matching overhead; then scope one direction—timing diagnostics, documentation, or an adapter. Done should include clear guidance or diagnostics, plus preserved argv, cwd, environment, streams, and exit-code behavior for any adapter.

Vom Indexierungsmodell aus dem Issue-Text verfasst.