feat: capture commit signature and PR base_ref in pull_request attestations

[AlexKantor87]

Producer side of kosli-dev/server#5892 — populates the new V2 pull_request attestation fields across all four SCM providers. Server counterpart: kosli-dev/server#5898 (merged).

✅ Ready — server-first ordering satisfied. The server schema (kosli-dev/server#5898, commit 91bcb8f) is now deployed to both kosli prods (prod-aws and prod-us-aws), so FoundPullRequestV2 accepts base_ref. CI is green against staging, which also carries the change.

Release note for cutting the next cli version: base_ref is rejected (extra_forbidden) by any server still pre-#5898. Self-hosted customers must upgrade the server before the cli (server-first) — worth calling out in the release notes.

What

Adds three optional fields to pull_request attestation evidence:

• commit-level verified (*bool) + signature_state (*string)
• PR-level base_ref

verified is tri-state: nil = unsigned/unknown, false = present-but-invalid, true = verified — so unsigned commits stay distinct from invalid signatures.

Provider coverage

Field	GitHub	GitLab	Bitbucket	Azure
verified / signature_state	✅ inline GraphQL	✅ +1 call/commit	❌ not in API	❌ not in SDK
base_ref	✅	✅	✅	✅ (raw refs/heads/…)

• GitHub — signature { isValid state } on the commit node + baseRefName, in both GraphQL paths.
• GitLab — TargetBranch → base_ref; per-commit GetGPGSignature, where a 404 means unsigned (handled, not fatal); other errors propagate.
• Bitbucket — destination.branch.name → base_ref; per-commit signatures not exposed by the API.
• Azure — TargetRefName → base_ref, kept raw (refs/heads/…) to match head_ref; per-commit signatures not exposed by the SDK.

All new fields are optional/omitempty, so other providers and existing consumers are unaffected.

Tests

Pure mappers unit-tested: GitHub buildPREvidence (signed / invalid / unsigned / base_ref), GitLab resolveGitlabSignature (404 / error / verified / unverified) + gitlabMRRefs, Bitbucket bitbucketBranchName, Azure azurePRRefs. go build ./..., go vet, and golangci-lint all clean. The full integration suite runs in CI.

🤖 Generated with Claude Code

[claude]

Claude finished @AlexKantor87's task in 3m 24s —— View job

---

Claude PR Review

• Static analysis (go build, go vet, go mod tidy)
• Review changed files
• Post review feedback

---

Reviewed the producer-side changes that populate verified / signature_state / base_ref across the four SCM providers. This is a clean, well-tested PR. Summary below; two non-blocking notes posted inline.

Static analysis ✅

• go build ./... — clean
• go vet ./... — clean
• go mod tidy → no changes to go.mod / go.sum

(The full integration suite needs the local Kosli server + provider tokens, so it runs in CI — the new logic is exercised by pure-mapper unit tests, which is exactly the right testability split.)

Strengths 👍

• Tri-state verified is modeled correctly. *bool + omitempty means nil (unsigned/unknown) is omitted, while &false (present-but-invalid) and &true are both serialized — a plain bool would have collapsed false into "unset". The distinction is explicitly tested (TestBuildPREvidence_Unsigned… vs …RecordsCommitSignature). Good call.
• GitLab 404-means-unsigned handling is isolated in resolveGitlabSignature and unit-tested for all four outcomes (404 → nil, non-404 → propagate, verified, unverified). Clear, well-commented, and the rationale references server#5892.
• Shared buildPREvidence keeps the two GitHub GraphQL paths (by-commit and by-PR-number) consistent — base_ref and signatures are populated identically in both, so the hybrid fallback doesn't drop fields.
• Small, pure mapper functions (gitlabMRRefs, azurePRRefs, bitbucketBranchName, gitlabCommitVerification) make the new behavior trivially testable without HTTP fakes.
• All new fields are omitempty, so other providers/consumers are unaffected. Migration story is sound.

Notes (non-blocking)

1. base_ref shape differs by provider — Azure sends refs/heads/main, the others send main. Intentional and self-consistent with head_ref, but a "merged into main" policy must handle both forms. Flagged inline on azure.go — worth confirming the policy/server layer normalizes or documenting it.
2. GitLab per-commit signature fetch is N+1 and can fail the whole attestation on a non-404 error. Deliberate (security intent), but a flaky signature endpoint can now abort an otherwise-valid pull_request attestation. Flagged inline on gitlab.go.
3. Minor — signature_state vocabulary differs by provider: GitHub emits GraphQL states (VALID, INVALID, …), GitLab emits its verification_status (verified, unverified, …). The verified bool normalizes the semantics, so this is only relevant if a consumer reads the raw string — just be aware downstream.

Draft status

Correctly marked draft: this sends base_ref, which FoundPullRequestV2 (extra="forbid") only accepts once server #5898 is deployed to prod. Good that the dependency is called out in the description — hold the merge until the server is live.

Nice work — the design decisions are sound and the test coverage on the pure mappers is exactly where it should be.
· claude/5892-pr-signature-baseref