docs(roadmap): state the Wear OS blocker against the policy as written

PRIVACY.md already documents Auto Backup and crash reports as ways data
can leave the phone, and there is a single build rather than an F-Droid
one. Say that, and call the entry blocked rather than unscoped.

Refs #27

docs/ROADMAP.md

@@ -618,11 +618,13 @@ Deferred deliberately, in rough priority order:
 - **Migrate Calendula and Agendula onto `core-prefs` + `core-di`**: tracked in
   the kit's roadmap, not here.
 - **Wear OS companion** ([#27](https://codeberg.org/jlmakiola/clockula/issues/27)):
-  unscoped. A watch that shows and controls the phone's timers and next alarm
-  needs a phone-to-watch channel, and the usual one, Google Play Services'
-  Wearable Data Layer, is a proprietary service that `docs/PRIVACY.md` and the
-  F-Droid build rule out. Any channel, ours or Google's, would also send data
-  off the phone, which the privacy policy currently says never happens. So
-  scoping this starts with a privacy decision, not with code. A standalone
-  watch app with its own timers and alarms and no sync avoids the question but
-  doesn't control the phone.
+  blocked on a privacy decision. A watch that shows and controls the phone's
+  timers and next alarm needs a phone-to-watch channel. The usual one, Google
+  Play Services' Wearable Data Layer, is a proprietary dependency that
+  `docs/PRIVACY.md` §2 rules out and that would ship in every channel, since
+  there is one build and no flavours. A channel of our own avoids the
+  dependency but is still a new way for data to leave the phone, which
+  `PRIVACY.md` would have to document next to Auto Backup and crash reports.
+  A standalone watch app with its own timers and alarms and no sync avoids the
+  question, but doesn't control the phone and has no F-Droid route onto a
+  watch.