feat(workflow): relax branch naming requirement in PR checks

[Mpfk]

Problem

The current PR checks enforce issue/{n} branch naming, which is overly restrictive. This creates friction for users of the Auto template who may use different branch naming conventions (e.g. Copilot's copilot/... branches, or feature branches from other tools).

Goal

Replace the strict issue/{n} check with two lighter requirements:

1. Not merging directly from main — the PR must come from a real branch.
2. Branch is linked to a GitHub Issue — via a closing reference in the PR body (e.g. Closes #N, Fixes #N, Resolves #N).

This keeps the issue-first discipline intact without mandating a specific branch naming scheme, making Auto easier to adopt as a template.

Acceptance Criteria

• PR from any branch name (other than main) that includes a closing reference passes the check
• PR from main fails the check
• PR with no closing reference to an issue fails the check
• Existing issue/{n} branches continue to pass (backwards compatible)
• Tests updated to cover the new branch-agnostic behavior

[github-actions]

Issue is ready. Branch ready: issue/73. Assign to Copilot 'develop' Agent to begin work.

[Mpfk]

Retrospective — Iteration 1

What was attempted: Add main-branch PR source guard to workflow-policy.yml, update branch-guard hook message, add bats coverage.

What passed:

• Policy guard correctly rejects PRs from main branch (confirmed via direct Node execution and bats test)
• All 65 existing tests continue to pass
• New tests are reliable positive-assertion style (discovered that != assertions in bats helper functions don't reliably fail — rewrote as == assertions matching the expected error message)

What failed (fixed mid-cycle):

• Initial !=-style test appeared to pass even before the implementation was in place due to BATS ERR trap behavior inside helper functions. Replaced with explicit positive match on the expected failure message string.

Open questions: None — implementation is complete and PR #74 is open.