core: split secret resolution into a pure plan and an executor

[domenkozar]

Motivation

secretspec/src/secrets.rs interleaves deciding what to do (profile merge via resolve_secret_config, provider alias resolution, grouping secrets by store, address derivation) with doing it (spawning threads, provider fetches, fallback retries, defaults, generation, temp files). Symptoms:

• validate_audited performs planning and execution in one pass; during review of the ref work (feat: native secret references (ref) as provider independent coordinates #121) the per group fetch logic sat inside an eight level nested closure before being extracted.
• The value free resolution report (check --explain/--json, report.rs/resolve.rs) is reverse engineered from the execution path rather than being an input to it, so the explanation and the execution can drift.
• Per secret decisions (effective config, route chain, address) are recomputed across get, set, batch validation, and fallback retries.

Proposal

Resolve everything up front into an immutable resolution plan, then execute it.

1. Plan (pure, no I/O): for each secret in the active profile, derive its effective config, its address (native ref coordinates or convention naming), and its route (provider chain after alias resolution, or the default provider). Fully unit testable without any provider.
2. Execute: a small executor consumes the plan: group by store, fetch groups concurrently, walk fallback chains, apply defaults, generate.

The existing ResolutionReport becomes the serialized plan plus per secret outcomes instead of a byproduct of execution.

Benefits

• Plan time validation: e.g. a ref carrying vault routed at a chain that includes dotenv can be rejected before anything is fetched; today unsupported coordinates surface at fetch time, per provider.
• check --explain is exact by construction.
• Concurrency (group fetches, ref coordinate dedup) lives in one small executor instead of being threaded through resolution logic.
• A pure, serializable plan is a good foundation for the SDK/FFI direction.

Migration

Can be grown incrementally out of the existing resolve.rs/report.rs types: port validate_audited first, then get/set.