CLI gen: --input/--output/--output-dir convenience options on every command

[HavenDV]

Part of #338. Complements gap #1 (per-parameter flags) and #4 (human formatters).

Today

Generated CLI emits only --request-file (path to a JSON file). No stdin support, no inline JSON, no output-to-file, no multi-file sink for paginated responses.

Firecrawl's Commands/ ships --input file.json|-, --output path.txt, --output-dir dir/ on every high-level command. Implemented entirely in CliRuntime once; reused across commands.

Target

# Read body from file, override one field
firecrawl scrape https://example.com --input ./scrape-config.json --only-main-content

# Read body from stdin
echo '{"formats":["markdown"]}' | firecrawl scrape https://example.com --input -

# Write formatted output to file
firecrawl scrape https://example.com --output result.txt

# Multi-page crawl, one file per page
firecrawl crawl https://example.com --wait --output-dir ./crawl-out/

Proposed approach

1. --input option (replaces --request-file semantically): accepts a path, - for stdin, or an inline JSON string starting with { or [. The loaded body is merged with per-field flags (gap build(deps): Bump the all group with 1 update #1) — flags override loaded fields.
2. --output option: when set, writes the rendered output (formatted or JSON depending on --json) to the given path instead of stdout.
3. --output-dir option: emitted only on commands whose success response is paginated, an array, or has known multi-resource shape (crawl results, batch results, deep-research artifacts). Writes one file per item with a stable naming scheme:
   • if the item has url → <sanitized-url>.md / .html / .metadata.json
   • else → 001.json, 002.json, ...
4. Add helpers to CliRuntime: ReadInputAsync(string spec) -> string, WriteOutputAsync(string? path, string content), WritePageResultFilesAsync(string dir, IEnumerable<T> items).
5. Backward compatibility: keep --request-file and --request-json as hidden aliases for --input (deprecation warning) so the rename doesn't break scripts.

Acceptance criteria

• All four invocations above work on regenerated Firecrawl.Cli.
• --input - reads stdin correctly when piped.
• --output-dir produces one file per page for crawl results.
• --request-json / --request-file still work with a deprecation warning.

[HavenDV]

Folding in #339 step 4 (--request-json as an overridable base body)

#339 step 4 asked for --request-json/--request-file to load a base body that per-field flags then override. Now that per-field flattening (#339) and positional hoisting (#340) have landed, this is cleaner to design here alongside --input, because it interacts with both.

Key design insight (low-risk, no ModelStyle construction needed): object-body commands bind to the SDK's flattened convenience overload, so a base body can be merged at the argument level rather than by reconstructing the request object:

await client.CreateWidgetAsync(
    name:     nameResult     is not null ? name     : @base.Name,
    tags:     tagsResult     is not null ? tags     : @base.Tags,
    priority: priorityResult is not null ? priority : @base.Priority,
    cancellationToken: cancellationToken);

Each convenience parameter type equals the body property type, so @base.<Prop> is always assignment-compatible — this sidesteps record with / readonly-record-struct constructor / class-initializer differences entirely (no ModelStyle branching).

Open design points to resolve here:

1. Required-flag relaxation. When a base is supplied, currently-required flags (and CLI gen: hoist path templates and obvious resource args to positional Argument<T> #340's required-but-not-hoisted options) must become optional, enforced instead by a validator: either a base (--input/--request-json) is present or every required field is supplied as a flag. Required = true is static at option construction, so this has to move to a command.Validators check.
2. Positional vs base conflict. A CLI gen: hoist path templates and obvious resource args to positional Argument<T> #340-hoisted body field (e.g. scrape <url>) is a required positional Argument. If a base body can also supply it, it can't stay a required positional. Options: keep positional required (base only fills non-positional fields), or demote the hoist to an optional flag when --input is in play. Path-template positionals are unaffected (they come from the URL, not the body).
3. Provided-detection. Per-flag parseResult.GetResult(option) is not null to distinguish 'absent' from 'explicitly set to default'.

Direct (raw string/array/enum/binary) bodies already use --request-json/--request-file as-is (no fields to merge), so this only concerns object bodies.

Deferring step 4 of #339 to this issue so the base-body ergonomics are designed in one place.