Populate SLSAProvenance fields from existing CI verification data at report-build time

[gkanitz]

Context

Wire the approved SLSAProvenance struct to the values already captured in the existing verification block at the point where the manifest is assembled. No new API calls or external data sources are introduced; every value comes from data already present in memory at report-build time.

Acceptance criteria

CI path (GitHub Actions workflow_dispatch or scheduled trigger)

Given a CI run where the existing verification block contains:

• workflow_ref: "jsmith/my-repo/.github/workflows/report.yml@refs/heads/main"
• run_id: "12345678"
• run_url: "https://github.com/jsmith/my-repo/actions/runs/12345678"
• action version tag/commit resolved at build time: "v0.2.1" / commit SHA "abc1234"
• report generation start timestamp: "2025-11-01T09:00:00Z"

The written manifest JSON contains:

{
  "slsa_provenance": {
    "build_type": "https://coderepute.dev/buildTypes/report@v1",
    "builder_id": "https://github.com/jsmith/my-repo/.github/workflows/report.yml@refs/heads/main",
    "invocation_id": "https://github.com/jsmith/my-repo/actions/runs/12345678",
    "started_on": "2025-11-01T09:00:00Z",
    "finished_on": "<timestamp recorded at the moment manifest assembly completes>",
    "resolved_dependencies": [
      { "uri": "https://github.com/gkanitz/CodeRepute@v0.2.1" }
    ]
  }
}

Note: the finished_on value is the wall-clock time at which manifest assembly completes; if this timestamp is not currently recorded, the developer agent adds the recording call and notes it in the PR description. The build_type URI https://coderepute.dev/buildTypes/report@v1 is a placeholder; the human reviewer confirms or replaces it before merge.

Non-CI path (local CLI invocation)

Given a run where GITHUB_ACTIONS is not set:

• The manifest is written without a populated slsa_provenance value (null or omitted, per the decision made in slice 2).
• All other manifest fields are identical to a run without this feature.

Non-CI path (programmatic Go API call)

Given a caller constructing a report via the public Go API without setting GITHUB_ACTIONS:

• The returned manifest struct has SLSAProvenance set to nil (or the zero value of the struct, if the developer agent uses a pointer type - developer agent chooses and documents the decision).
• Marshalling the struct to JSON produces the same output as the CLI non-CI path above.

No new external I/O

• No HTTP calls, file reads beyond the existing verification block, or environment variable reads beyond GITHUB_ACTIONS and the variables already used by the existing verification block are introduced.
• Confirmed by code review (no new network client instantiation in the wiring code path).

Integration test

TestManifestWrittenWithSLSAProvenanceCI: using a table-driven test with a stubbed verification block and GITHUB_ACTIONS=true, read back the written manifest file and assert every slsa_provenance field matches the expected literal values from the table.

Scope / files

• The manifest assembly / report-writing function(s) in the existing codebase (exact paths confirmed by developer agent).
• Corresponding _test.go file(s).

Out of scope

• Changing the schema struct itself (done in slice 2).
• Any signing, Rekor submission, or post-write attestation step.
• Adding new environment variable reads beyond GITHUB_ACTIONS and those already used.

Gates

go test ./..., go vet ./..., gofmt -l .

Blocked by: #107