docs(dev): developer portal rewritten; tier definition closed in the standard

development.md was a bare link list whose 'implementation guides'
blurb still taught the pre-RLS visibility pattern. Now it's the
developer-tier portal: contributing/development.md as the start-here
(architecture/setup/testing — fresh and maintained), the gated API
reference with its per-area entry points and the openapi.yaml mirror,
the four protocol docs, the under-the-hood guides (RLS visibility,
scanner sidecars, calibre OPF, tag-normalization contract, Android
design), the standards (writing-ui-docs, glossary, contract pins),
and the gates enumerated — routes<->docs, Bruno parity, links, labels,
RLS invariant. writing-ui-docs.md's Developer-tier line closes the
open tone question: how-it-works, source-pinned, external software
linked not paraphrased.

docs/developer/writing-ui-docs.md

@@ -86,9 +86,12 @@ make the page followable even if that label is renamed next week.
   No API-client detail: request and response schemas live in the developer
   docs. The calibration in one line: **user = what you see, admin = what
   it does, developer = how it works.**
-- **Developer section — tone is a separate discussion, not yet decided.**
-  Write it plainly and hand-off-rich as well; do not import opinions about
-  its voice until that pass happens.
+- **Developer section — source-pinned and wire-accurate.** The
+  developer tier is *how it works*: wire formats, data access, pipeline
+  mechanics, and enforced rules, every claim grounded in source the way
+  admin docs ground behavior. External software (device installs,
+  third-party tooling) is linked to its project's documentation, not
+  paraphrased. (Decided 2026-11-02, closing the earlier open question.)
 
 ## Generate what has a registry