[Feature] Define best-effort concurrency error handling and preserve structured stream errors

[mbe24]

Problem

Concurrent hydration and enrichment paths do not yet follow one explicit policy across providers. This can lead to inconsistent behavior when one branch fails: sometimes we should fail fast, other times we should continue with warnings.

Additionally, stream-mode failures after partial writes should preserve the original structured AppError category/exit code instead of collapsing to a generic provider error shape.

Design

Adopt a uniform concurrency policy:

1. fail fast for required branches (primary fetch/decode, top-level search page),
2. best-effort for optional enrichment branches (links/comments/review comments where optional),
3. preserve original structured error category in stream mode while reporting partial-output context.

Scope

• Define and apply required-vs-optional branch policy across provider hydration/search paths.
• Standardize warning behavior for optional branch failures.
• Preserve AppError category/exit code in stream error paths with partial-output context.
• Add test coverage for required-failure, optional-failure, and stream partial-output behavior.

Boundary

• No new CLI flags or config keys in this phase.
• No redesign of global error taxonomy/exit-code mapping.
• No tracing schema overhaul beyond minimal context additions for partial output.

Acceptance Criteria

• Required branch failures stop the item/command path with the original structured error category.
• Optional branch failures emit warnings and continue without dropping the whole item.
• Stream-mode failures after partial output keep original category/exit code and include partial-output context.
• Behavior is consistent across providers and covered by tests.

Context

Recent concurrency work improved latency significantly, but error handling policy now needs to be explicit and uniform so behavior is deterministic for both humans and automation.

• Tokio join! macro: https://docs.rs/tokio/latest/tokio/macro.join.html
• Rust error handling patterns (Result): https://doc.rust-lang.org/book/ch09-00-error-handling.html