docs(roadmap): record why a Wear OS companion is blocked on Play Services

A companion needs Google's Wearable Data Layer, which is a proprietary
service the privacy policy and the F-Droid build rule out. The roadmap
entry now records that constraint, what the bridged notifications
already give a watch, and the options if it is picked up.

Refs #27

docs/ROADMAP.md

@@ -617,4 +617,19 @@ Deferred deliberately, in rough priority order:
   notification surface is known (`PLAN.md` §3).
 - **Migrate Calendula and Agendula onto `core-prefs` + `core-di`**: tracked in
   the kit's roadmap, not here.
-- **Wear OS companion**: unscoped.
+- **Wear OS companion** ([#27](https://codeberg.org/jlmakiola/clockula/issues/27)):
+  unscoped, and blocked on one constraint. A companion that shows and controls
+  the phone's timers and next alarm needs a phone-to-watch channel, and the only
+  practical one is Google Play Services' Wearable Data Layer
+  (`play-services-wearable`). That is a proprietary third-party service, so it
+  would break `PRIVACY.md`'s "no third-party service of any kind" and the
+  F-Droid build. What already works without it: ring, timer and snooze
+  notifications are bridged to a paired watch by the system, so the wrist
+  already gets the ring and its actions. The options, if this is ever picked up:
+  - **Standalone watch app**: its own timers, stopwatch and alarms on the watch,
+    no Play Services and no sync. Fits the privacy promise but does not control
+    the phone.
+  - **Play-only companion**: the Data Layer confined to a Play Store flavour, so
+    F-Droid builds stay free. It means two flavours with different features and
+    a privacy policy that has to describe the difference.
+  - **Leave it**: rely on the bridged notifications and do nothing more.