compat: SemVer version windows between app and server

Both sides now declare what they will talk to, and enforce it. Two axes kept
deliberately separate, because conflating them is the trap:

  protocol_version  — CAN these builds talk. The correctness axis. Below 1.0.0
                      the minor is the breaking axis, per SemVer §4.
  release window    — MAY they, per policy. [min, max), advertised in the
                      profile, overridable by the operator.

The server refuses out-of-window apps with 426 and a body naming both versions
and the accepted range; the app checks the profile in both directions before a
run rather than discovering mid-measurement that it will be refused.

Three rules that shape the rest:

  - GET /v1/profile is never gated. It is where a refused client learns which
    version it needs; gating it leaves the user with a network error instead of
    an answer, which is precisely the confusion this exists to remove.
  - An unparseable or absent version is "unknown", and is allowed. Development
    builds report "dev", and a client too old to send the header cannot be
    identified anyway.
  - Bounds sit at breaking boundaries, not at releases, so shipping a patch
    never requires editing a range. The app's server minimum is 0.4.2 for a
    stated reason: earlier multi-homed servers mis-addressed granted sends and
    the client measured 100% downstream loss that never happened.

The app's versionCode is now derived from its SemVer instead of being a second
number someone has to remember to bump.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/probe-protocol.md

@@ -192,14 +192,77 @@ Note: exact RDATA constants to be frozen in the implementation's `dns_reference.
 
 Same daemon, separate listener (default localhost-only): health + self-test (are both IPs live, is the canary zone delegated correctly, is UDP reachable from outside — tested via a public echolot "mirror" if configured), enrollment token management (create/expire/scope), device list + revocation, retention settings, QR rendering (client-side JS). Out of scope for this spec beyond the endpoints above.
 
-## 8. Cross-references to the measurement schema
+## 8. Version compatibility
+
+Both artifacts are versioned with **SemVer**: the Go server (`server-vX.Y.Z` tags) and the Android
+app (`versionName`; `versionCode` is derived from it, never maintained separately). Two independent
+things are checked, and conflating them is the mistake this section exists to prevent.
+
+### 8.1 Protocol version — *can* these builds talk?
+
+`protocol_version` is the version of **this document**. It is advertised in the profile
+(`compat.protocol_version`) and is the correctness axis: a peer in a different breaking series
+cannot be talked to, whatever its release version says. Below `1.0.0` the **minor** is the breaking
+axis (SemVer §4); at and above it, the major is. A patch bump of the protocol never splits a fleet.
+
+### 8.2 Release-version window — *should* they, per policy?
+
+Each side declares the range of peer release versions it will work with, as `[min, max)` —
+**minimum inclusive, maximum exclusive**, because the useful bound is always "the version that
+broke it" and writing that literally is unambiguous. An empty maximum means unbounded.
+
+The server advertises its window and enforces it:
+
+```jsonc
+"compat": {
+  "protocol_version": "1.0.0",
+  "schema_version": "1.0.0",
+  "app_min": "0.2.0",
+  "app_max": "1.0.0"     // exclusive; "" = no upper bound
+}
+```
+
+Operators override it with `ECHOLOT_MIN_APP_VERSION` / `ECHOLOT_MAX_APP_VERSION` (or
+`--min-app-version` / `--max-app-version`). A malformed bound is **fatal at startup**, not ignored:
+a typo must not silently disable a restriction the operator meant to set.
+
+The app sends its version on every control-plane request:
+
+```
+X-Echolot-App-Version: 0.2.0
+```
+
+and carries its own bounds for the server (`MIN_SERVER` / `MAX_SERVER` in `Compat.kt`). It checks
+the profile in **both** directions — is the server in our range, and are we in the server's — so a
+mismatch is reported before a run starts rather than discovered halfway through one.
+
+### 8.3 Rules
+
+1. **`GET /v1/profile` is never gated.** It is where a refused client learns which version it needs.
+   Gating it leaves the user with a network error instead of an answer, defeating the check.
+2. **Refusal is `426 Upgrade Required`**, with a body naming both versions and the accepted window:
+   ```json
+   { "error": "app 0.1.0 is older than this build supports (needs >= 0.2.0, < 1.0.0). Update the app.",
+     "app_version": "0.1.0", "accepts_app": ">= 0.2.0, < 1.0.0",
+     "server_version": "0.5.0", "protocol_version": "1.0.0" }
+   ```
+3. **An unparseable or absent version is `unknown`, and is allowed.** Development builds report
+   `dev`, and a client too old to send the header cannot be identified anyway. The check exists to
+   turn confusing failures into clear ones; refusing what it cannot identify does the opposite.
+4. **Bounds move at breaking boundaries, not at releases.** Shipping a patch must never require
+   editing a range. A minimum is raised only when older peers are actually harmful — e.g. the app
+   requires server `>= 0.4.2` because earlier multi-homed servers sent granted traffic from an
+   address the session never used, which the client measured as 100 % downstream loss. A
+   confidently wrong measurement is worse than a refused one.
+
+## 9. Cross-references to the measurement schema
 
 - Observation-block fields (§3.3) appear as `*_seen_by_server` columns in `train` evidence (schema §6.2).
 - `TIMESYNC` (§3.2) produces the `time.server_offset` test; without it, cross-clock fields must not be compared (schema §6.2 note).
 - Capability strings (§2.3) are copied verbatim into `server_sessions[].capabilities` (schema §5); tests skipped for missing capability get `status: "unsupported"`.
 - `session_id` maps to `server_sessions[].session_id`; `action_id`s appear in test `params`.
 
-## 9. Open items
+## 10. Open items
 
 1. Whether TRAIN_REPORT should also stream during long trains (partial reports every N packets) for live UI feedback — leaning yes, same type with a `flags` bit.
 2. Throughput methodology (fixed streams vs BBR-style ramp) — decide with `perf.*` test design.