feat(crewing): Phase 2 — requisitions + relief requests (flagged)

Second slice of the Crewing module per wiki Crewing-Implementation-Spec §12
(build order item 2). Everything stays behind NEXT_PUBLIC_CREWING_ENABLED;
production is unchanged. Schema is added incrementally — this lands the
requisition lifecycle layer.

What's in
- Schema: Requisition (OPEN→SHORTLISTING→PROPOSING→INTERVIEWING→SELECTED→FILLED,
  →CANCELLED), ReliefRequest, CrewAction (the POAction mirror) + their enums.
  Migration crewing_requisitions.
- State machine: lib/requisition-state-machine.ts mirrors po-state-machine
  (selection Manager-only; orthogonal cancel from OPEN/SHORTLISTING by
  cancel_requisition holders, §6). Codes REQ-9000… via lib/requisition-number.ts.
- Actions: raise/cancel/transition + requestReliefCover/convertReliefToRequisition,
  each guarding flag+permission+state, writing a CrewAction and notifying. Shared
  autoRaiseRequisition() (lib/requisition-service.ts) is the backfill entry point
  for sign-off / leave-clash (later phases).
- Notifier: notifyCrew() PO-independent path + CrewNotificationEvent.
- Screens: /crewing/requisitions (list + Raise modal + relief convert) and
  /crewing/requisitions/[id] (detail). Requisitions added to the flag-gated
  Crewing sidebar (Manager + MPO, §7).

Tests & docs
- Unit: requisition-state-machine.test.ts (11).
- Integration: requisitions.test.ts (15) — raise/cancel/transition, relief
  request + convert, auto-raise, permission gating.
- CLAUDE.md "Crewing" section updated with the Phase 2 surface.

Deferred: sign-off/experience (Epic K, §12 item 2) depends on the crew/assignment
models from Phase 3/4; autoRaiseRequisition() is ready for it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.forgejo/workflows/pr-checks.yml

@@ -1,20 +1,22 @@
 name: PR checks
 
 # Enforces the contribution policy on every PR into master — plus the crewing
-# integration branch (feat/crewing-foundations), which collects the stacked,
-# feature-flagged crewing phases before they merge to master. Same hard gates:
+# stack branches (feat/crewing-*), which collect the stacked, feature-flagged
+# crewing phases (foundations → requisitions → candidates → …) before they merge
+# to master. Same hard gates:
 #   - code changes must ship with tests (docs/config/automation are exempt)
 #   - type-check is clean across the whole project (tests included)
 #   - unit tests pass
 #   - integration tests pass against an ephemeral Postgres (migrate + seed)
 # Runs on the pms1 host runner. See automation/README.md > "Contribution policy".
 #
-# Note: for pull_request events the workflow is read from the BASE branch, so a
-# base must appear in this list for its incoming PRs to be checked.
+# Note: the workflow is evaluated from the branch under test, so the trigger list
+# must match it. The feat/crewing-* glob covers every branch in the stack so each
+# stacked phase PR is checked without further edits to this file.
 
 on:
   pull_request:
-    branches: [master, feat/crewing-foundations]
+    branches: [master, "feat/crewing-*"]
 
 jobs:
   checks: