ci: KEEP-1304 bring the issue-first gate to parity with keeperhub

[suisuss]

Issue

No GitHub issue. Team change, tracked as KEEP-1304, in the branch name and both commits.

check-issue-link will fail on this pull request, and that is the bug being fixed. The gate currently on main reads a reference only from the title and has no team path, so a ci: pull request from a repository branch cannot satisfy it however it is written. Under the gate this pull request installs, the Linear ticket in the branch name passes it. Re-run the check after merge and it goes green.

What this changes

This repository ran a first-generation copy of the issue-first gate and had drifted from KeeperHub/keeperhub on eight points:

	keeperhub	cli before
Reference read from	title, description (HTML comments stripped), branch	title only
Multiple references	up to ten candidates, any accepted passes	first #N only
Team pull requests	Linear ticket in the branch name passes	absent, so a team PR with no #N fails
Failure feedback	one comment on the PR, edited in place	job log only
synchronize trigger	present	absent, so the check went stale after a push
Re-run when an issue is accepted	recheck-issue-link.yml	absent
decision-label-check	present	absent
Exempt types	docs chore style release	docs chore style

pr-issue-link.yml is replaced with the keeperhub version, adapted only for main. recheck-issue-link.yml and decision-label-check.yml are new here. ISSUES.md, CONTRIBUTING.md and the pull request template are widened to describe what the gate now accepts, since all three documented title-only referencing and three exempt types.

Two things a reader would not predict from the title:

• recheck-issue-link.yml needs actions: write to re-run a workflow run. The other two need no new permissions; pr-issue-link keeps pull-requests: write for its comment, which is why the file forbids adding a checkout step.
• The gate being replaced documented its own bug. Its failure text ended: "Already labelled 'accepted'? This check does not rerun by itself when the issue changes - re-run the job, or edit the PR title to retrigger it." That instruction is what recheck-issue-link.yml removes, and I quoted it in the new file's header so the reason it exists stays on the record.

Scope

One unit. The three workflows and the three documents state one rule, and shipping the gate without the prose would leave ISSUES.md describing a check that no longer behaves that way - the documents are the contract contributors are held to.

The real motivation is a disagreement this drift caused: babysit-prs/queue.sh extracts title + description + branch and uses one exempt-type list for both repositories, and says in a comment that the sweep and CI cannot disagree about what counts. For cli that was false - the review sweep could report a pull request as accepted or exempt-type that CI failed. Parity makes the comment true again, which is why the fix belongs here rather than as a special case in the tooling.

How it was verified

No Go changed; go build and go test are untouched by this diff.

• All three workflows parse as YAML, and every extracted run: body passes sh -n.
• The candidate-extraction block is byte-identical to keeperhub's, checked by diff.
• No staging or prod reference leaked into the ported files.
• Trigger and permission sets confirmed per workflow: pull_request_target / issues / pull_request.
• The decision-needed comparison was exercised on both branches before porting: a label set containing it blocks, one without passes.

Not verified: the issues trigger firing here. It cannot be until this is on main. It was verified end to end in keeperhub, where the same file went from label to green check in nine seconds.

Screenshots

Renders nothing.