docs: make the path from clone to merged PR followable

[Muawiya-contact]

What & why

Someone who clones this repo today gets four cargo lines in the README
and four more in CONTRIBUTING, both of which assume a working toolchain
and neither of which says what to install, what to work on, or what the
failures mean. This makes the path from git clone to a merged PR
something a person can actually follow.

New: docs/DEVELOPMENT.md

Prerequisites per platform, the fast engine-only loop, the app, the
site, how to run exactly what CI runs, and a table of failures with the
message as it really appears. Two of those cost real time and are
invisible from the code:

• A machine with rustc but no C linker can't run even cargo check,
  and says linker 'cc' not found.
• Building the app without the Linux webview packages fails naming
  glib-2.0, not webkitgtk, because glib-sys is the first *-sys
  crate to fall over — so the error gives no hint which four packages
  you actually need.

Both were reproduced rather than recalled. There's also a container
recipe for machines where a C compiler can't be installed at all, with
the Podman/Docker file-ownership difference noted, since that one leaves
root-owned files in your checkout.

Rewritten: CONTRIBUTING.md

Leads with the honest answer to "what should I work on": rules. The
database is thirteen rules, everything else on a disk classifies as
unknown and is dropped, and adding one needs no Rust — so the
highest-value contribution is also the lowest barrier, and that should
be the first thing a newcomer reads.

Also written down, because they are currently learned by having a PR
turned down: a wrong safe verdict isn't cosmetic, since safe and
review are both actionable in the app; and capability belongs in the
engine with the frontends rendering what it returns. Plus commit and PR
conventions taken from what this repo actually does, a table of which
file a given intent belongs in, and a checklist that matches CI exactly.

Extended: docs/ARCHITECTURE.md

A scan walked through the engine stage by stage, each step naming the
function that does the work and why it sits where it does — plus a
section on choosing the layer for a new feature, which is the decision
most likely to be got wrong and most expensive to unpick in review.

Corrections

Documentation that had drifted from the code:

• The pipeline diagram was wrong. lib.rs and the core README drew
  scanner ─► index ─► dedup ─► graph ─► rules + risk ─► report. Dedup
  moved after classification when non-actionable entries were excluded
  from it, and there has never been an index module — that stage reads,
  to someone opening the crate, like a file they failed to find.
• The CLI sample output showed one reason per finding, from before it
  printed all of them, so the example omitted exactly the evidence that
  makes a verdict make sense.
• The app README listed no commands, though the webview can now call
  six.
• The FAQ claimed a macOS release. The app builds and CI compiles it
  on macOS, but the release entry is commented out pending a developer
  account, so that was a promise nothing keeps.

Verified, not assumed

Every command and error message in the new guide was run. Beyond that:

• all relative links across every markdown file in the repo resolve
• typos (the exact version CI uses) passes
• the nine commit types documented are all in the actual history
• the thirteen rules were counted from base.json, not remembered

Checklist

• cargo fmt --all and cargo clippy --workspace are clean
• cargo test --workspace passes
• Commits are small and focused (one logical change each)
• Doesn't weaken a safety principle — docs only, plus one comment
  fix in lib.rs; no behaviour change

[Muawiya-contact]

ok