ci: unpin system-map caller — track .github@main (ORO-1936)

[that-guy-wade]

Follow-up: the dispatcher is a first-party, branch-protected reusable workflow, so SHA-pinning the caller only added re-pin toil. Track ORO-AI/.github@main instead — dispatcher changes (the empty-PAT guard + toJSON payload hardening) now apply automatically.

[shardi-b]

Review of PR #253 — ci: track ORO-AI/.github@main for system-map caller

Scope: Single file, .github/workflows/system-map.yml, +3/-4 lines. The functional change replaces the pinned reusable-workflow reference uses: ORO-AI/.github/.github/workflows/sync-system-map.yml@3bf228bc48733185867f30db9a5c53c86d98bea4 with @main, and rewrites the header comment to explain that the caller now tracks the branch-protected first-party dispatcher repo instead of a pinned SHA.

Correctness: No defects found. The on: triggers, the least-privilege permissions: block, the fork-skip guard (if: github.event.pull_request.head.repo.fork == false), and the secrets: MAP_SYNC_PAT forwarding are all unchanged. The @main ref is a valid reusable-workflow reference and behaves identically at call time to the previous SHA pin. No inverted conditions, no dropped guards, no syntax errors, and no call-site breakage.

Non-blocking note (supply-chain): Moving from a pinned SHA to a mutable @main ref while continuing to forward the MAP_SYNC_PAT secret does technically widen the trust surface — a compromise of, or unauthorized push to, main of ORO-AI/.github could alter the reusable workflow and exfiltrate the PAT across every mapped caller repo. That said, this is a deliberate, self-documented tradeoff for a first-party, branch-protected repo (avoiding a per-caller SHA bump on every dispatcher change), which is an accepted org-internal practice. It does not constitute a blocking defect.

Decision: No finding scores 80 or above. Approve.