The CLI tests timed out once at 30s, and nothing since has reproduced it

Observed while running the gates on [#564](https://github.com/akiomik/nostui/pull/564). Recording it because a wall-clock bound that fires without a regression turns a green suite red, and the next person to see it deserves to find this rather than start over.

## What happened

One `just test` run:

```
running 3 tests
test result: FAILED. 0 passed; 3 failed; 0 ignored; 0 measured; 0 filtered out; finished in 30.00s
```

All three tests in `tests/cli.rs`, all at once, at exactly `RUN_TIMEOUT` — 30.00s for the binary as a whole, which is the three of them hitting the bound in parallel rather than one after another. `just lint` and `RUSTDOCFLAGS='-D warnings' just doc` had run immediately before it in the same shell command.

Every run since has been green in about a second:

```
test result: ok. 3 passed; ... finished in 0.96s
test result: ok. 3 passed; ... finished in 0.98s
test result: ok. 3 passed; ... finished in 0.90s
test result: ok. 3 passed; ... finished in 1.25s
```

CI on the same commit was green too. So: one occurrence, not reproduced.

## What it is not

- **Not the change under test.** #564 touches only `src/domain/nostr/nip27.rs`, which these tests reach only by linking.
- **Not contention over the log file.** All three processes open the same `initialize_logging` file before parsing, which reads like a shared resource — but `logging.rs` only calls `File::create`, with no lock and nothing to block on.
- **Not the first run of a freshly linked binary.** That was the state when it happened, so I tried it deliberately: `touch src/main.rs && cargo test --test cli` relinks and runs immediately. Green in 1.25s.

## Why it is worth a bound at all

`tests/cli.rs` explains the 30s: without it a regression that let the binary get past argument handling would reach `ratatui::init()`, and crossterm opens `/dev/tty` rather than the piped stdout — so on a developer's machine it would take the real terminal and wait for input forever. The bound turns that into a failure instead of a suite that hangs with no output ([#561](https://github.com/akiomik/nostui/pull/561)).

So the bound should stay. The question is whether 30s of wall clock is the right way to ask it, given that the comment right above it says nothing here should take a measurable amount of time — the gap between "measurable" and 30s is where this failure lives, and a loaded CI runner is the same shape of machine.

## What would settle it

- Whether the run really was stalled, or the timeout fired on a process that had already exited: `assert_cmd`'s timeout kills and reports, and the output of the killed runs was not captured. Printing what the process produced before the kill would tell these apart, and is worth doing whether or not the cause is ever found.
- Whether anyone else has seen it. One occurrence in roughly ten full-suite runs on one machine is all the evidence there is.

Start in tests/cli.rs by reading the RUN_TIMEOUT setup and the assert_cmd invocation. Run cargo test --test cli and inspect how output from timed-out processes is reported, comparing it with the documented parallel 30-second failure. Done means the timeout behavior is understood and the bound or its diagnostics have a justified outcome.

由索引模型根据 Issue 内容生成。