refactor(policies): expose project context via input.chainloop_metadata

[migmartri]

Summary

Replaces the bctx.Context-based project context plumbing introduced in #3094 with input-level injection. The rego engine now merges project_name / project_version_name into input.chainloop_metadata at evaluation time, so policy authors can read them from input and forward them as operands to chainloop.* built-ins:

effective := chainloop.effective_assessments({
    "project_name":         input.chainloop_metadata.project_name,
    "project_version_name": input.chainloop_metadata.project_version_name,
    "finding_type":         "VULNERABILITY",
    "lookups":              lookups,
})

The previous bctx.Context mechanism had no consumers in the codebase — built-ins receive operands plus context but do not read input, and the EE built-ins that will consume project scope take it as part of their request payload. Exposing the values on input is the simpler contract: authors see and pass the values explicitly, mirroring how chainloop.discover already reads input.chainloop_metadata.digest.

The public API (engine.WithProjectContext, policies.WithProjectContext, crafter wiring, and the chainloop policy develop eval --project / --project-version flags) is unchanged. Existing keys on input.chainloop_metadata (e.g. the intoto descriptor populated for materials) are preserved.

Refs #3090

Test plan

• go test ./pkg/policies/... (370 tests)
• chainloop policy develop eval --policy <p> --material <m> --kind <k> --project demo --project-version v1.2.3 and confirm a policy reading input.chainloop_metadata.project_name sees the value alongside the existing material descriptor fields

[cubic-dev-ai]

No issues found across 6 files