CLI gen: emit --wait/--poll-interval/--wait-timeout for create+poll operations

Part of #338.

Today

AutoSDK already detects create→poll→terminal patterns at the SDK level via --auto-detect-status-polling, generating <Method>WaitAsync companions. The CLI generator does not use this signal. Users have to chain shell commands:

JOB=$(firecrawl api crawling crawl-urls --request-json '{...}' | jq -r .id)
while true; do STATUS=$(firecrawl api crawling get-crawl-status --id "$JOB" | jq -r .status); [[ "$STATUS" == "completed" ]] && break; sleep 5; done

Target

firecrawl crawl https://example.com --wait --poll-interval 5s --wait-timeout 30m

Proposed approach

1. When EndPoint.PollingMetadata indicates this operation is the create side of a detected create→poll pair, emit three additional options:
   • --wait (Option<bool>, default false)
   • --poll-interval (Option<TimeSpan>, default 00:00:02) — parsed via CliRuntime.ParseDuration helper that accepts 2s/30m/1h/raw seconds.
   • --wait-timeout (Option<TimeSpan>, default 00:30:00) — same parser.
2. When --wait is set, the generated action calls the existing <Method>WaitAsync helper (already generated by the SDK side) instead of returning after create.
3. The wait helper already handles terminal state detection — CLI just consumes it.
4. Output is the terminal-state response, formatted via the gap-#4 formatter (or --json for raw).
5. Add CliRuntime.ParseDuration to the generated CliRuntime.cs template.

Vendor extension

x-cli-wait: true|false|always on an operation can force/suppress wait support when auto-detection misses or is wrong (e.g. operations with status-polling-shaped responses that aren't actually long-running).

Acceptance criteria

• Firecrawl crawl, scrape (batch variant), extract, deep-research, llmstxt commands all accept --wait after regeneration.
• Runway.Cli polling commands work via generated --wait without hand-written wrappers.
• --poll-interval 250ms, --poll-interval 5s, --poll-interval 1h all parse correctly.
• Without --wait, behavior is unchanged (returns the create response).

Trace how the CLI generator consumes EndPoint.PollingMetadata and inspect the existing SDK-side WaitAsync helper and generated CliRuntime.cs template. Add the generated wait options, duration parsing, and x-cli-wait handling without changing the default create response. Regenerate the Firecrawl and Runway.Cli commands and verify the listed duration values and terminal-state output.