docs(repo): align the public contribution text with the forge's actual doors

CONTRIBUTING.md told strangers to fork and "open a Pull Request". Measured
against the forge itself, that door is shut: the API reports
has_pull_requests=false / has_issues=true for open/portfolio-optimiser, and
the org's published CONVENTIONS.md states the position -- "Issues velkommen
som signaler. PRs ikke akseptert. Fork-and-own er anbefalt adopsjonsmodell."

Replaces the PR workflow with the two routes that are actually open (issues
as signals, fork-and-own), and keeps the engineering standards the section
carried -- load-bearing tests, blocking validator, ruff/mypy, Conventional
Commits -- reframed as what the project holds itself to, which is what a
forker needs and what an issue is weighed against.

Also points CLAUDE.md's commons link at open/portfolio-optimiser-commons
(published 2026-08-04). The `commons` git remote still resolves via ktg/ and
is deliberately left alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GWsexbQjPo9rsV3aUE54ZS

CLAUDE.md

@@ -14,7 +14,7 @@ Python ≥3.10. MAF (`agent-framework-core` 1.9.0). Pakkehåndtering: `uv`. To b
 - Modell-valg som konfig (modell-map rolle→Foundry-deployment), ikke spredt i kode.
 - Metode kodifiseres som **Agent Skill** (`agentskills.io`: `SKILL.md` + `scripts/` + `references/`).
 - Datatilgang: in-process `FunctionTool` er default-sømmen i kjørestien; **MCP er extension point**, demonstrert via `build_mcp_server` (`datasource.py`) men ikke wiret inn i kjørestien. Data-source-konfig JSON-Schema-validert, fail-fast.
-- `shared/` er en **git subtree** av [`portfolio-optimiser-commons`](https://git.fromaitochitta.com/ktg/portfolio-optimiser-commons) (source of truth, R1 realisert 2026-07-03; remote `commons`). Synk er **pull-only**: endringer committes i commons og hentes med `git subtree pull --prefix=shared commons main --squash`. ALDRI `git subtree push` fra konsument — re-split lekker hele konsument-historikken inn i commons (observert + opprydd 2026-07-03). Se `shared/README.md`.
+- `shared/` er en **git subtree** av [`portfolio-optimiser-commons`](https://git.fromaitochitta.com/open/portfolio-optimiser-commons) (source of truth, R1 realisert 2026-07-03; publisert i `open/` 2026-08-04 — `commons`-remoten peker fortsatt på `ktg/` og virker uendret). Synk er **pull-only**: endringer committes i commons og hentes med `git subtree pull --prefix=shared commons main --squash`. ALDRI `git subtree push` fra konsument — re-split lekker hele konsument-historikken inn i commons (observert + opprydd 2026-07-03). Se `shared/README.md`.
 
 ## Kommandoer
 - Sync: `uv sync`

CONTRIBUTING.md

@@ -15,32 +15,40 @@ Please read and follow our [Code of Conduct](CODE_OF_CONDUCT.md).
 - Provide clear reproduction steps
 - Include relevant environment details (OS, Python version, backend profile)
 
-### Submitting Changes
+### Pull requests are not accepted
 
-1. Fork the repository
+The pull-request tab is **switched off** on this forge, across every repository in the
-2. Create a feature branch (`git checkout -b feature/amazing-feature`)
+organisation. That is a published position, not an oversight: this project is solo-maintained,
-3. Make your changes following the conventions below
+and an enabled-but-permanently-empty PR queue would promise a review capacity that does not
-4. Run the test, lint, and type checks (see Development Setup) and ensure they pass
+exist.
-5. Commit your changes using [Conventional Commits](https://www.conventionalcommits.org/)
-   (`type(scope): description`)
-6. Push to your branch and open a Pull Request
 
-### Pull Request Guidelines
+Two routes are open instead:
+
+- **Issues** — welcome, and read as signals. A well-argued issue carries the same information
+  as a patch and costs you less to write.
+- **Fork-and-own** — the recommended adoption model. The licence is MIT: fork it, take it in
+  your own direction, and you owe nothing back.
+
+## Standards this project holds itself to
+
+These are the conventions the code is written against. They are worth knowing if you fork, and
+they are what an issue about the code will be weighed against:
 
 - Follow the existing code style (`ruff` enforced)
 - Type hints everywhere; `mypy`-clean where possible
-- Include tests for new functionality — this project uses **load-bearing tests**: a test that
+- Commit with [Conventional Commits](https://www.conventionalcommits.org/)
+  (`type(scope): description`)
+- New functionality comes with tests — this project uses **load-bearing tests**: a test that
   covers a seam must fail when that seam is detached, not merely pass while wired
 - The **deterministic validator is mandatory and blocking** — never make it an optional plugin
-- Keep PRs focused on a single change
+- Documentation is updated in the same change
-- Update documentation as needed
 
 ## Development Setup
 
 Requires Python ≥ 3.10 and [`uv`](https://docs.astral.sh/uv/).
 
 ```bash
-# Clone your fork
+# Clone (upstream, or your own fork)
 git clone https://git.fromaitochitta.com/open/portfolio-optimiser.git
 cd portfolio-optimiser