State the compatibility baseline and the channels

NFR-COMPAT-1 and NFR-COMPAT-2 were instructions to write a requirement,
not requirements: "state the API level", "state the channels". Both
are now stated from what the build enforces and what exists.

The baseline is minSdk 28 / targetSdk 36 from the Android Dockerfile,
a Vulkan adapter at wgpu's default limits because compute needs storage
textures — device_from already called that the floor and is tagged for
it — with no optional feature required, since the f16 in FR-DEV-2 is a
texture format and not shader arithmetic. The reference device is the
HONOR ROD2-W09 the figures are taken on, and the second-vendor clause is
recorded as unmet rather than quietly dropped: there is no Mali or
PowerVR device, so an Android figure here is an Adreno figure.

The channels are all self-distribution — Arch package, local Flatpak,
sideloaded APK, NSIS installer — because D13's face weights rule out
every store, and the two consequences are written down: SAF stays
although a sideloaded build need not have it, and S11 becomes a
pre-publication step.

docs/requirements.md

@@ -1887,24 +1887,46 @@ selection.
 
 ### 4.8 Compatibility baseline
 
-**NFR-COMPAT-1 — Supported hardware.** Every §4.1 Android figure is meaningless without this. State:
+**NFR-COMPAT-1 — Supported hardware.** Stated 2026-09-19 from what the build enforces and the
+hardware the figures are taken on. Every §4.1 Android figure is measured against this.
 
-- Minimum and target Android API level (targetSdk 36 is currently required for Play distribution)
-- Minimum Vulkan version and the required feature and limit set — including whether `shaderFloat16`
-  and 16-bit storage are required, since **FR-DEV-2's f16 pipeline depends on them and their
-  absence would jeopardise R1**
-- Minimum device RAM, and minimum desktop Vulkan/Mesa versions
-- The **specific** reference Android device the §4.1 column is measured on, plus a secondary device
-  from a different GPU vendor
+| | Baseline |
+|---|---|
+| Android API | **minSdk 28**, targetSdk 36 (`docker/android/Dockerfile` `MIN_API`/`ANDROID_API`; the linker targets 28, so the binary runs on the oldest level it claims) |
+| GPU, both platforms | A **Vulkan** adapter accepted by wgpu at its **default limits** — not the downlevel tier — because storage textures in compute shaders are required; `dr_gpu::GpuContext::device_from` states this as the floor. No optional feature is required: `required_features` is empty. The pipeline stores intermediates in `Rgba16Float` textures, which are core Vulkan; **`shaderFloat16` arithmetic is not required** and FR-DEV-2's "16-bit float" is a storage precision, not a shader-arithmetic one. The GL backend is accepted on desktop as a last resort |
+| Desktop | Linux with a Mesa or vendor Vulkan driver the reference machine's era or later; Windows under NFR-COMPAT-2's installer. No minimum Mesa version is asserted beyond "wgpu's default limits are met" |
+| RAM | No figure asserted; NFR-P8's budgets are the constraint, not the device's total |
+| **Reference Android device** | **HONOR ROD2-W09**, Qualcomm SM8635 (Adreno), 12 GB, Android 16 / API 36, 1920×3000 at 400 dpi. Every Android column in §4.1 is measured on it |
+| Second-vendor device | **None.** The clause asking for a Mali or PowerVR device is **unmet and known unmet**: no such hardware exists in the project, and S2's two-vendor run is blocked on it (#47). Until one exists, an Android figure in this document is an Adreno figure |
 
 Adreno, Mali, and PowerVR diverge significantly in compute behaviour and in external-memory interop
 — exactly what spike S1 tests. The spec already applies this reasoning to desktop drivers; it
-applies at least as strongly on Android.
+applies at least as strongly on Android, which is why the missing second vendor is recorded as a
+gap rather than dropped.
 
-**NFR-COMPAT-2 — Distribution channels.** State the v1 channels (e.g. Flatpak and AppImage on Linux;
-Play Store and/or F-Droid on Android). Play distribution is what makes ARCH §6.9's constraints binding —
-a sideloaded or F-Droid build could use different permissions, so the channel decision and the
-storage design are coupled.
+*A figure worth noting.* At 400 dpi the reference tablet's portrait width is roughly 768 logical
+pixels, which is under D15's assumed ~1024 and under `EXPANDED_MIN_WIDTH`. Whether Slint's scale
+factor agrees with the platform density is open issue N6; this row records the measurement and
+does not resolve it.
+
+**NFR-COMPAT-2 — Distribution channels.** Decided 2026-09-19. Every channel is
+**self-distribution**: built by the Gitea CI from one commit, installed by hand, and published to
+no store or catalogue. That is a consequence of D13 — the face weights' grant rules out every
+public channel — and it is the position until those weights are replaced.
+
+| Platform | Channel | Built by |
+|---|---|---|
+| Linux | Arch package (`packaging/PKGBUILD`) | CI, `packaging/pkg/` |
+| Linux | Flatpak from the manifest in `packaging/flatpak/`, installed locally — **not** submitted to Flathub | CI |
+| Android | Signed release APK, sideloaded (`docker/android/assemble-apk.sh`, the release key of 2026-09-11) — **not** Play, **not** F-Droid | CI |
+| Windows | NSIS per-user installer cross-built from Linux (`docker/windows/`, FR-PLAT-WIN-3) | CI |
+
+Two consequences the channel decision has on the requirements above it. ARCH §6.9's SAF-only
+storage model was written because Play would reject anything else; a sideloaded build *could*
+request broader permissions, and FR-PLAT-AND-1 keeps SAF anyway, because the design is right on
+its own terms and because the day a public channel opens is not the day to redesign storage.
+And S11, the Play permissions dry-run, becomes a pre-publication step rather than a Tier-1 spike:
+there is nothing to submit until D13 is closed.
 
 ### 4.9 Accessibility and internationalisation