feat: add structured progress logging to cr review

[rianjs]

Summary

• add structured stderr breadcrumbs to cr review command/runtime, GitHub provider IO, live planning, and durable LLM task execution
• extend the shared progress component with structured fields so review-path logs can carry model, harness, session, task, and run metadata
• add focused command, pipeline, and progress tests for GitHub IO, LLM execution/resume, cached task reloads, and live planning breadcrumbs

Testing

• rtk go test ./...

Closes #364

[rianjs]

The added tests are directionally useful, but they still do not prove the user-facing contract for cr review.

• [blocker] I do not see an integration-style test in internal/cmd/reviewcmd/reviewcmd_test.go that captures real stdout/stderr and asserts progress breadcrumbs go only to stderr. Helper-level coverage can still pass if progress leaks to stdout, is swallowed, or never gets wired into runReview/runLive at all.
• [blocker] I do not see coverage for --quiet across the whole wrapper stack in internal/cmd/reviewcmd/provider_progress.go, internal/cmd/reviewcmd/adapter_progress.go, internal/cmd/reviewcmd/live_progress.go, and internal/cmd/reviewcmd/pipeline_progress.go. A regression that ignores opts.Quiet for GitHub IO, planning, or durable task execution would still satisfy the current test shape.
• [major] The new coverage in internal/pipeline/pipeline_test.go and internal/progress/progress_test.go looks too field-formatting-centric. It should assert that start/resume/load flows preserve task_id, phase, source, session_id/resume_session_id, and run_id in the emitted record. Otherwise a refactor can drop task/session context and the tests would still pass.
• [minor] I do not see coverage proving the "regular breadcrumbs" part of the requirement, only that some progress spans exist. If the implementation regressed to one-shot start/end logging, this suite would not catch it.