[cardano-testnet] Enhancements for status command #6747

Today each node row shows the name, role, state, pid and tip (slot, block, age), and the JSON adds pidAlive and the tip hash. A few additions would make the report more useful when something goes wrong:

1. Point at the logs of a node that is down or unreachable. The manifest already records each node's stdoutFile and stderrFile, but status does not read them. Printing the stderr.log path, or its last line, for an unhealthy node answers the first question a user has, with one file read and no network call.
2. Mempool size and capacity per node. This shows transactions that are stuck or not accepted. cardano-api exposes it through queryTxMonitoringLocal with LocalTxMonitoringMempoolInformation. The tx monitor cannot share a state-query session, so this needs a second N2C connection per node, with its own timeout, run only after the tip query has succeeded.
3. Era, epoch and slot in epoch. The report does not show where the chain is in time. One executeLocalStateQueryExpr session can bundle queryCurrentEra and queryEpoch. These are the same on every node, so querying one healthy node is enough, and slot in epoch can be computed from the Shelley genesis that status already reads. The manifest's network.era is the era the testnet started in, so it can be stale after a hard fork.

Two lighter ideas, which need no new queries because they use data status already fetches:

• Blocks behind the best tip. A column with each node's distance from the best tip in block numbers shows which node is falling behind before it counts as stalled.
• Fork detection. Two nodes at the same block number with different tip hashes are on different forks. The hash is already in the JSON, so a warning in the summary would be cheap.

Potential enhancement, out of scope for this PR: node metrics such as peer counts, blocks forged, missed slots and memory use. They come from cardano-tracer's Prometheus endpoint, which exists only with --enable-tracer, and its port is not written to the manifest (only the in-memory TestnetRuntime has it). Supporting this needs an optional manifest field and an HTTP client, so it fits a follow-up PR better.

Originally posted by @carbolymer in #6741 (comment)