Docs: add a first-contribution workflow for docs-only contributors

Adding a concrete draft structure that might be easy to adopt:

1. Who can contribute (issue-first, invited code PR policy)
2. Fast path for docs-only contributors (how to propose wording, expected evidence, minimal checks)
3. Bug triage contribution template (repro, expected/actual behavior, logs)
4. When maintainers invite a PR (criteria and handoff expectations)

This could preserve the current invitation-only policy while still giving external contributors a clearer path to contribute useful analysis/docs.

Quick implementation draft to reduce maintainer review overhead:

1. Add a short "First Contribution (Docs)" section in docs/contributing.md with a 4-step path (find issue -> propose wording -> run checks -> open PR).
2. 2. Include one copy-ready PR checklist snippet focused on docs-only contributions.
3. 3. Add minimal validation commands contributors can run locally before submitting.
4. 4. Add a clear maintainer-invite criterion line so contributors know when code changes are expected vs docs-only guidance.

If useful, I can open a docs-only patch with these exact section headings so review can stay small and fast.

Given the current docs/contributing.md policy says external code contributions are invitation-only, I think this docs change should avoid telling first-time contributors to open unsolicited PRs. A lower-friction section could be issue-first and still give maintainers copy-ready material.

Suggested text shape:

## First-time external contributions

External code PRs are by maintainer invitation. The best first contribution is high-quality issue analysis that maintainers can verify quickly.

1. Pick an existing open issue before starting new work.
2. Reproduce the behavior on the latest release or current `main` when possible.
3. Comment with the exact command, version or commit, expected behavior, actual behavior, and the smallest suspected owner path.
4. If the issue is docs-only, propose exact replacement wording in the issue thread first.
5. Wait for a maintainer invitation before opening a PR.

Useful issue comment checklist:

- Codex version or commit
- OS, shell, and install source
- Minimal command or steps
- Expected behavior
- Actual behavior
- Logs or failing assertion, trimmed to the relevant lines
- Suspected files/modules, if known
- Whether this affects only OpenAI/Codex auth paths or also local/custom providers

That would cover docs-only contributors without conflicting with the invite-only PR rule. It also gives bug triagers a clear path to contribute value even when opening a PR is not appropriate.

Quick follow-up with a maintainer-friendly minimal shape (if this direction still fits):

Suggested docs block: "First contribution path (docs-only)"

• where docs-only contributors should start (CONTRIBUTING.md + docs index)
• minimum pre-PR checks (format, link validation, issue linkage)
• a tiny PR template snippet focused on:
• scope (what changed)
• user impact (why it helps)
• validation (how checked)

This keeps onboarding lightweight while still preserving review quality and traceability for contributors who are not changing runtime code.