(CAT-2632) Enable safe fork-PR CI against private puppetcore

[LukasAud]

Adds a two-track CI pattern so fork PRs can run acceptance tests against the private Puppet Forge under layered controls.

• New reusable fork_ci_label_guard.yml strips the allowed-for-ci label on every fork-PR synchronize, so each new commit re-requires a fresh CODEOWNER review and re-label before the privileged acceptance workflow can run.
• module_acceptance.yml: acceptance job conditionally targets the puppetcore-fork GitHub Environment (per-run reviewer approval) for fork PRs only; the second checkout now uses the PR head SHA with persist-credentials disabled; env-var passthrough applied to all user-controlled interpolations in run blocks; third-party actions pinned to SHAs.
• module_ci.yml: matching hardening (permissions, SHA pins, persist-credentials, env passthrough). Both reusable workflows gain a defense-in-depth if: so unlabeled fork PRs cannot run under pull_request_target.
• example/module/ci.yml: rewritten to the two-track pattern (pull_request for Spec without secrets; pull_request_target gated by label for Acceptance). synchronize intentionally omitted from pull_request_target types to avoid racing with the label guard.
• New docs/how-to/fork-pr-ci.md covers per-module adoption (label, ruleset, environment, branch protection) and the reviewer checklist for files that warrant scrutiny before applying the label.

Checklist

• 🟢 Spec tests.
• 🟢 Acceptance tests.
• Manually verified.

[gavindidrichsen]

Approving — clean two-track design, and the threat model in the how-to is thorough. Left two optional mermaid diagrams inline (two-track flow + label lifecycle)
to make fork-pr-ci.md legible at a glance — take or leave them.

[gavindidrichsen]

A diagram here would make the two-track model legible at a glance — it's the reviewer's mental model for the whole design. Suggesting it right under the heading so the prose bullets below still read as the step-by-step detail:

Suggested change

	## How it works
	## How it works
	```mermaid
	flowchart TD
	PR([Fork PR opened / updated]) --> spec
	subgraph public["Spec track — pull_request (no secrets)"]
	spec[Spec: rake spec]
	end
	subgraph privileged["Acceptance track — pull_request_target (secrets in scope)"]
	guard{"allowed-for-ci<br/>label present?"}
	review[["CODEOWNER reviews diff:<br/>Rakefile, spec/**, Gemfile,<br/>.fixtures.yml, metadata.json"]]
	env["approval_gate job<br/>→ puppetcore-fork environment<br/>(reviewer compares head SHA)"]
	accept[Acceptance: litmus:*<br/>PUPPET_FORGE_TOKEN in scope]
	end
	PR --> guard
	guard -- no --> stop1([No acceptance run])
	review -- applies label --> guard
	guard -- yes / labeled --> env
	env -- approved --> accept
	```

[gavindidrichsen]

This bullet describes the subtlest control in the design — the close→push→reopen replay and why the closed trigger defeats it. A state diagram of the label lifecycle makes it reviewable at a glance, and it maps 1:1 to fork_ci_label_guard.yml (the file this PR adds). Suggesting it right after this bullet:

Suggested change

	- If the PR is closed, `fork_ci_label_guard.yml` also fires on `closed` and removes the label. This prevents an attack where a contributor closes the PR, pushes new commits (no events fire on a closed PR), then reopens — without close-strip the label would persist across the reopen and the new commits would inherit the prior authorisation. Side effect: closing a merged PR also strips the label, which is cosmetic (the label is only meaningful for open PRs).
	- If the PR is closed, `fork_ci_label_guard.yml` also fires on `closed` and removes the label. This prevents an attack where a contributor closes the PR, pushes new commits (no events fire on a closed PR), then reopens — without close-strip the label would persist across the reopen and the new commits would inherit the prior authorisation. Side effect: closing a merged PR also strips the label, which is cosmetic (the label is only meaningful for open PRs).
	```mermaid
	stateDiagram-v2
	[*] --> Unlabeled
	Unlabeled --> Labeled: CODEOWNER applies<br/>allowed-for-ci (after review)
	Labeled --> Acceptance: pull_request_target<br/>type=labeled → approval gate
	Labeled --> Unlabeled: synchronize (new commit)<br/><b>guard strips label</b>
	Labeled --> Unlabeled: closed<br/><b>guard strips label</b>
	note right of Unlabeled
	closed-strip defeats the reopen attack:
	close → push (no events fire) → reopen
	would otherwise carry the stale label
	onto unreviewed commits.
	end note
	Acceptance --> Unlabeled: next synchronize<br/>re-requires fresh review
	```