Expose a terminal/IO capability to routes and rendered scripts (TTY-ness, color, columns) instead of each plugin re-detecting it #511

Summary

cli-entry.ts already decides whether stdout is a TTY (options.isTty ?? (() => process.stdout.isTTY === true)) to pick color for rendered documents, but nothing of that reaches route code: CliRouteProps / ScriptRouteProps are { input | argv, signal } and the agent context has no IO/terminal capability. A plugin that emits anything itself (progress on stderr, a streamed child process's output, ANSI-bearing text) has to re-implement TTY and NO_COLOR/FORCE_COLOR/CLICOLOR/TERM detection per fd. cargo-hauler does this in src/client/exec.ts (colorEnabled(env, process.stderr.isTTY)), and every other plugin with a hot path outside the rendered document will too.

Request

Add a read-only capability on the agent context (and to ScriptRouteProps for plain/rendered scripts), e.g.

context.io: {
  stdout: { isTTY: boolean; color: boolean; columns: number | null };
  stderr: { isTTY: boolean; color: boolean; columns: number | null };
  sharesTarget: boolean; // fd 1 and fd 2 are the same open file (2>&1 shape)
}

computed once by the framework with the same rules cli-entry.ts uses (so plugin output and framework output agree), and overridable in the in-process test harness (test/cli.ts, test/script.ts already have an isTty knob — this is the same knob, surfaced). Where Effect's Terminal service (effect/Terminal, provided by @effect/platform-node NodeTerminal) applies — columns/rows, line input for interactive scripts — back it with that rather than a parallel implementation; note Terminal.display is string-only and stdout-only, so it does not replace raw two-channel byte forwarding, which is why the capability should be information, not a writer.

Non-goals

Not asking the framework to take over stdout for plain scripts; docs/entry-conventions.md's "ordinary Node stdout/stderr semantics" for src/scripts/** is right. Just the detection.

Version

agent-bundle preview 42539ff5f (main).