docs(android): link the M11 app PRs and name the remaining gate

Both parts are built: Android-app#30 (the visibility rules + read-model adds)
and #31 (the four screens, stacked on it). The on-device five-rung walk against
a website on the cutover branch is what edge->main is now actually waiting on.

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

android/PLAN.md

@@ -913,6 +913,10 @@ push, and Play (M6–M8) follow the designed app.
     `/public/shard/features` simply `404`s, and each consumer below falls back to exactly today's
     behavior. The app declares no protocol version and never talks to the sidecar.
 
+    **Both parts are built and in review:** Part 1 `RunicGateway/Android-app#30`, Part 2 (stacked on
+    it) `#31`. 336 unit tests pass and lint is clean on both; the on-device five-rung walk below is
+    the remaining gate, and it is what the cutover is actually waiting on.
+
     - **Part 1 — the visibility rules + the read-model adds.** The security-shaped half, reviewed on
       its own:
       - `GET /public/shard/features` → `{ level, features[] }`: the features **this caller** may reach.

link/v3.md

@@ -961,9 +961,12 @@ request rides the same authenticated OkHttp client as every other call, so an ap
 the same audience rung as the same account on the web; and every shard DTO in the app is
 nullable-with-defaults, so field projection strips fields without a deserialization failure.
 
-Scoped as **M11 in [`../android/PLAN.md`](../android/PLAN.md) §9**, two PRs (the visibility rules +
+Scoped as **M11 in [`../android/PLAN.md`](../android/PLAN.md) §9**, two PRs: the visibility rules +
-read-model adds, then the four screens). `edge` → `main` is held until both land, so web and app
+read-model adds ([Android-app #30](https://gitea.whitlocktech.com/RunicGateway/Android-app/pulls/30))
-surface the same shard on the same day. Neither PR is coupled to the merge order — on a pre-v3 website
+and the four screens ([#31](https://gitea.whitlocktech.com/RunicGateway/Android-app/pulls/31), stacked
+on it). Both are **built and in review**; the on-device five-rung walk (§11) against a website on the
+cutover branch is the remaining gate. `edge` → `main` is held until both land, so web and app surface
+the same shard on the same day. Neither PR is coupled to the merge order — on a pre-v3 website
 every new route and `/public/shard/features` `404`s and the app falls back to today's behavior — so
 holding the cutover is a schedule decision, not a technical dependency.