ci: add system-map auto-sync caller (ORO-1936)

[that-guy-wade]

Adds the system-map auto-sync workflow (ORO-1936) for the validator layer. On any PR to main, hands off to the shared dispatcher in ORO-AI/.github (SHA-pinned), which regenerates the validator layer of oro-system-map and opens an auto-merging sync PR there. Least-privilege permissions, fork-gated, explicit MAP_SYNC_PAT secret. No-op until the secret is present.

[shardi-b]

Reviewed PR #252 (ci: add system-map auto-sync caller), a single new 27-line workflow at .github/workflows/system-map.yml, at high effort across all 8 finder angles (correctness, removed-behavior, cross-file, reuse, simplification, efficiency, altitude, conventions).

The workflow is well-constructed and I found no blocking issues:

• The fork gate if: github.event.pull_request.head.repo.fork == false correctly skips fork PRs (where the MAP_SYNC_PAT secret would be empty) while allowing internal branch PRs.
• The reusable workflow is SHA-pinned (@3bf228bc...), matching the stated supply-chain-safety intent.
• Permissions (contents: read, pull-requests: read) are genuinely least-privilege: the caller's GITHUB_TOKEN only needs read access so the dispatcher can regenerate the map, while the cross-repo PR creation in oro-system-map uses the separate MAP_SYNC_PAT. No scope is missing.
• Passing MAP_SYNC_PAT: ${{ secrets.MAP_SYNC_PAT }} is safe when the secret is absent (resolves to empty string, no error); the "no-op until secret present" behavior lives in the dispatcher, which is out of scope for this diff.
• Trigger types [opened, synchronize, reopened] on main are standard and correct.

No finding scores 80 or above. Approving. (Note: the dispatcher sync-system-map.yml in ORO-AI/.github is not part of this diff and was not reviewed; the caller correctly delegates to it.)