feat(pr-detection): Autodetect PR information

[javirln]

Implemented automatic detection and collection of Pull Request (GitHub) and Merge Request (GitLab) metadata during attestation initialization when running in CI/CD PR/MR contexts.

Key Features

Automatic PR/MR Detection

• Detects GitHub PR context from GITHUB_EVENT_NAME and GITHUB_EVENT_PATH
• Detects GitLab MR context from CI_PIPELINE_SOURCE and merge request environment variables
• Extracts metadata: platform, type, number, title, description, branches, URL, author

New Material Type: CHAINLOOP_PR_INFO

• Added CHAINLOOP_PR_INFO material type to workflow contracts
• Automatically collected during attestation init in PR/MR contexts
• Stored as JSON evidence with schema validation

Schema Generation & Validation

• Created internal/prinfo package with typed Go structs
• Programmatic JSON schema generation using jsonschema annotations
• Schema validation enforces required fields and enum constraints
• Schema: https://schemas.chainloop.dev/prinfo/1.0/pr-info.schema.json

Implementation Details

• pkg/attestation/crafter/prmetadata.go: Detection logic for GitHub/GitLab
• pkg/attestation/crafter/materials/chainloop_pr_info.go: Material crafter with validation
• app/cli/pkg/action/attestation_init.go: Auto-collection during init
• Best-effort collection - failures don't block attestation

[jiparis]

Probably it's been already discussed:

• why a new material? We have attestation metadata for other related properties in the crafting state (attestation)
• why in attestation init and not in push?
• also, should it be optional?

[jiparis]

don't we have this CAS logic already elsewhere?

[javirln]

We have this logic on attestation push

[jiparis]

I see it's also in attestation add, so maybe it can we moved to a common function and reuse it. Something like:

var casBackend = &casclient.CASBackend{Name: "not-set"}
if !action.dryRun && attestationID != "" {
    casBackend, err = getCASBackend(ctx, attestationID) 
    ...
}

[javirln]

@jiparis the refactor