docs: add contributing instructions

[4ndrelim]

Benefits

1. Clarity: New contributors understand the workflow immediately
2. Consistency: Team follows the same practices
3. AI-friendly: Claude, Copilot, and other tools can learn project conventions
4. Safety: Clear rules prevent accidental breaking changes
5. Flexibility: Supports both careful testing and fast iteration

---

Notes

Refer to CONTRIBUTING.md for context. I've taken the liberty to make some assumptions / slight tweaks, explained below:

1. Proposed a simplified branch naming convention, using only prefixes feat/* and fix/*, but we enforce semantic classification (e.g. docs, chore, feat, fix, ci) in PR titles. [1]
2. Note the standard branching flow (proposed to branch off staging before raising PR to staging and subsequently from staging to main) [2]
   • Not sure if we should do this over branching off main. On one hand, main should always present the latest stable version, but it is also natural to branch off staging since it is the target branch of the merge after development.
3. Note the merging strategy [3]

IMPORTANT NOTE:

1. It seems make test is currently failing for some existing test cases. To investigate or inform the relevant owners.
2. @Junyi-99 I have disabled Automatically request Copilot code review for PRs to main but included it for PRs to staging since the new workflow expects heavy / complex changes to first PR to staging before main. To avoid double-review, i disabled this for PRs to main. Let me know if you would like to change or revert this.

---

Tasks

• Create CONTRIBUTING.md with branching strategy section
• Configure branch protection rules in GitHub settings
• Set up automated version bumping (if not already configured)
• Document this in README.md or link to CONTRIBUTING.md
• Announce new policy to team

[Junyi-99]

nice! thanks for contributing this pr!