docs: add model contribution skill and placement guidance

[hsliuustc0106]

Purpose

Contributors need an explicit workflow for adding models, including code placement, tests outside src/, and the documentation that must accompany an implementation.

Add the optional add-new-model skill and link it from CONTRIBUTING.md. The skill covers pinned inference contracts, model-owned execution and shared backend integration, repository-level tests and Rust test registration, validation, and a file-by-file documentation checklist. PRs #19 and #55 serve as worked examples, with current placement rules taking precedence over historical layouts.

The contributor guide makes the test-placement rule explicit: test bodies, helpers, and fixtures belong under root tests/; only external test-module registration wiring may remain in src/.

Test Plan

System1-Omni Version / Commit: base 1be7d41eb74d5b49fd25194042041319950e5dce; head 8066aa5bf7770f728382e7e801d02aeac62b3ad6.

Validate the skill, build the documentation with the pinned requirements, check relative links and the rendered skill link, and review the complete two-file diff.

Test Result

Passed locally:

• quick_validate.py .agents/skills/add-new-model: valid skill frontmatter and content.
• mkdocs build --strict: passed using an existing environment matching docs/requirements.txt.
• Relative Markdown links: all eight resolve; the built contributor guide routes the hidden skill link to GitHub.
• git diff --cached --check: passed.

The full diff was reviewed for scope, architecture, placement guidance, documentation accuracy, and reference links. Rust and GPU checks were not run because this change only adds documentation and skill instructions. No accuracy or performance claims are made.

Self-review

Before marking this PR ready for review or requesting maintainer review, complete
the contributor self-review checklist.
The PR is a draft; the contributor checklist remains for the author to complete.

• I have reviewed the full diff and addressed the issues I found.
• I have checked that the change follows the project's architecture and stays focused on the stated purpose.
• I have run the checks appropriate to this change and reported commands, results, and anything I could not verify above.
• I have checked that the PR description, documentation, and any accuracy or performance claims match the implementation and available evidence.