#1400 Expose workflow inputs in WorkflowReportContext

Problem

Workflow-scope reports cannot access the workflow invocation inputs. The WorkflowReportContext interface (in src/domain/reports/report_context.ts) and WorkflowReportArgs (in src/domain/workflows/workflow_report_runner.ts) have no inputs field, even though the runtime already stores them on the WorkflowRun aggregate and PR #1963 surfaces them in WorkflowRunView.inputs for the terminal data box.

Proposed Solution

Add an optional inputs?: Record<string, unknown> field to WorkflowReportContext:

export interface WorkflowReportContext extends BaseReportContext {
  scope: "workflow";
  workflowId: string;
  workflowRunId: string;
  workflowName: string;
  workflowStatus: "succeeded" | "failed";
  inputs?: Record<string, unknown>;  // <-- new
  stepExecutions: Array<{ ... }>;
}

Then pass run.inputs through WorkflowReportArgs into the context construction in WorkflowReportRunner.runFor().

Use Case

Our @webframp/morning-pulse-report workflow accepts regions, repo, and costDays as inputs. The report currently re-derives the region list by parsing model names from stepExecutions (aws-alarms-us-east-1 → us-east-1). With context.inputs.regions available directly, the report could:

1. Show which regions were requested vs which produced data (coverage gaps)
2. Display the invocation parameters in the report header for audit trail
3. Avoid brittle name-parsing logic that breaks if naming conventions change

Similarly, @webframp/adopt-drift-check passes modelName and stackName as inputs — the drift report currently reads stackName from the plan data artifact rather than from the workflow inputs that triggered it.

Alternatives

Reports can partially work around this by reading stepExecutions[0].globalArgs or by reading the plan step's data artifact, but both are indirect. The inputs are already on the run object — just not threaded into the report context.