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>

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 +
-read-model adds, then the four screens). `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
+Scoped as **M11 in [`../android/PLAN.md`](../android/PLAN.md) §9**, two PRs: the visibility rules +
+read-model adds ([Android-app #30](https://gitea.whitlocktech.com/RunicGateway/Android-app/pulls/30))
+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.