Modernize contributor workflow and local-development documentation

### Description

Align the contributor documentation with the repository’s current branches, local tooling, verification commands, pull-request process, and security practices so a new contributor can make a compliant change without relying on obsolete wiki guidance.

### Action Items

- [ ] Audit `docs/CONTRIBUTING.md`, repository READMEs, the wiki links it references, and onboarding materials for obsolete or conflicting guidance.
- [ ] Replace the outdated `master`/`dev` branching model with the approved current branch and pull-request flow; coordinate final branch policy with #745.
- [ ] Document the supported local toolchain and setup path, including mise, Node.js, pnpm, dependency installation, and any Docker prerequisites that remain current.
- [ ] Document the expected local verification commands, pre-commit/pre-push behavior, and how contributors should interpret or resolve failures.
- [ ] Explain the pull-request workflow: issue linkage in Related Issues, the compliance check, review expectations, and how to respond to requested changes.
- [ ] Add concise safe-handling guidance for local configuration and secrets, aligned with #746 and #747.
- [ ] Validate every external/internal link and either update, replace, or intentionally retire stale wiki references.
- [ ] Ensure the documentation has a discoverable canonical location and avoids duplicating generated or volatile workflow details.
- [ ] Have a contributor or maintainer follow the documented happy path and correct any gaps found.

### Additional Information

Known gap: `docs/CONTRIBUTING.md` currently documents `master` and `dev`, whereas existing workflows target `main` and `stable`.

Related work: #739 (PR compliance), #744 (local/CI GitHub Actions validation), #745 (merge-governance spike), #746 (secret scanning), and #747 (security policy).

Start with docs/CONTRIBUTING.md, the repository READMEs, linked wiki pages, and onboarding materials; compare their branch, setup, verification, pull-request, and security guidance with current repository workflows. Read related issues #745, #746, and #747 before changing policy-dependent sections. Done means the canonical documentation is consistent, links are validated, and a contributor or maintainer completes the documented happy path without gaps.

Written by the indexing model from the issue text.