downloads_dir secret-resolution is triplicated across recorder/cli/replay

[HappyDevs1]

What's happening

This block is copy-pasted verbatim in three places:

browser.downloads_dir.as_deref()
    .map(flowproof_trace::secret::resolve_refs).transpose()?
    .map(std::path::PathBuf::from)

• crates/flowproof-agent/src/recorder.rs (web_browser_from_setup)
• crates/flowproof-cli/src/lib.rs (stage_surface_browser)
• crates/flowproof-replay/src/lib.rs (run_trace_with_exports)

Each caller then re-threads the result into an already-6-argument
WebBrowserConfig::from_setup_parts(...) call
(crates/flowproof-driver/src/app.rs:1106-1113), which already carries
#[allow(clippy::too_many_arguments)] — clippy's own threshold is being
suppressed, not met. viewport/user_agent/args/clock/random/downloads_dir
travel together at every one of the four call sites as same-typed positional
Options, which is fragile to a silent transposition.

If we don't fix it

This is secret-resolution code (flowproof_trace::secret::resolve_refs) —
exactly the kind of logic where three copies are how a future change lands in
two of three places and the third silently regresses. The charter's invariant
is "no secret ever reaches a trace"; a single source of truth for how a
browser secret gets resolved is cheaper to keep correct than three.

If we fix it

One helper (e.g. resolve_downloads_dir(&Option<String>) -> Result<Option<PathBuf>, _>),
or fold the resolution into WebBrowserConfig::from_setup_parts itself so
callers pass the raw staged value and stop repeating the ladder. Consider
bundling viewport/user_agent/args/clock/random/downloads_dir into
one struct at the same time, removing the clippy suppression and the
positional-argument fragility together.

Before closing

No behavior change is expected — this is a pure refactor. Existing coverage
across the three call sites should be sufficient to prove nothing moved;
flag if any gap surfaces once the helper exists.