[CanReader]

What this changes

staging becomes the testing layer in front of main. Every change lands in staging first, and main only takes pull requests from staging once CI passes. The game itself is untouched; only CI configuration and docs change.

• .github/workflows/branch-policy.yml fails any pull request into main that does not come from this repository's staging branch. It runs on pull_request_target, so a pull request cannot edit the check into passing, and it checks out nothing.
• CI also runs on pull requests into and pushes to staging. Each push to staging uploads the Windows and Linux Release builds as artifacts, so they can be play-tested before release.
• .github/rulesets/main.json and staging.json are importable rulesets: pull requests only, CI must pass, no force pushes or deletion; main additionally requires the branch policy check and merge commits.
• Dependabot opens its updates against staging.
• CONTRIBUTING.md documents the flow; the pull request template points at staging.
• engine-update.yml gets issues: write, so the issue it opens when an engine change breaks the game is no longer refused. This is groundwork for the engine pinging SleakCraft on every push, as it already does for SleakEngine-FPP and SleakEngine-Empty.

Why

To keep main safe: changes get tested in staging before they reach main.

How it was verified

• Builds on Linux
• Loaded a world and played it
• Placed and broke blocks
• Saved, quit, reloaded, and the world was intact
• Not runtime tested (explain why below)

No game code changes. Checked instead:

• The branch policy logic against 10 source/target cases, including a fork with its own branch named staging.
• Both rulesets against GitHub's REST API schema, and every required check name against the real CI job names.
• actionlint with shellcheck on every workflow.

This pull request is the first real run of the updated CI.

Checklist

None apply: no shader, save format, collision, or event handler changes.