Make dashboard artifact availability use one captured run context

Context

A read-only audit during #439 found that dashboard artifact availability is not consistently bound to one captured run context.

artifactPathsForAttempts() accepts a request-scoped runRoot, but still consults mutable this.currentRunId to decide whether the request is a preview. It also catches every listSafeFiles() error and reports the artifact directory as though it were simply empty.

This does not weaken the separately verified findings/report authority added in #439, so it should not block that issue. It can still make logs, rendered prompts, patches, and metadata availability inconsistent or hide malformed-present artifact directories.

Desired behavior

• Carry both run ID and run root in the captured dashboard request context; do not mix either with mutable current selection state.
• Treat only genuine absence as unavailable.
• Surface malformed-present, dangling, unsafe, permission, and unexpected enumeration failures instead of converting them to an empty artifact list.
• Keep the existing strict containment/no-symlink rules.

Acceptance coverage

• Switching the selected run during a request cannot change artifact availability for that request.
• A missing artifact directory is reported as unavailable.
• A dangling or malformed-present artifact directory fails visibly.
• Findings/report endpoints remain bound to their existing verified run-wide authority snapshot.

Found while auditing #439; follow-up from draft PR #457.

Start at dashboard request context and artifactPathsForAttempts(), then inspect how listSafeFiles() and the findings/report endpoints obtain run identity and artifact availability. Done means one request uses its captured run ID and root, missing directories remain unavailable, malformed or unexpected enumeration failures surface visibly, and the existing containment rules and authority snapshot behavior remain intact.