docs(roadmap): keep the Wear OS note to what holds

Ringing notifications are foreground-service notifications, so making
them non-ongoing wouldn't bridge them; CompanionDeviceManager carries no
data; and watches pair through their makers' apps. Say only what holds
and note that a watch build has no F-Droid channel.

Refs #27

docs/ROADMAP.md

@@ -618,24 +618,19 @@ 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. The part the issue describes, a watch that shows and controls the
-  phone's timers and next alarm, needs a phone-to-watch channel. The usual one
-  is Google Play Services' Wearable Data Layer (`play-services-wearable`), a
-  proprietary service that `docs/PRIVACY.md` ("no analytics, tracking,
-  advertising, crash-reporting SDK or third-party service of any kind") and the
-  F-Droid build rule out. Other channels (a Bluetooth link of our own through
-  `CompanionDeviceManager`) haven't been looked into.
-  Today a watch gets little: ring and timer notifications are ongoing, which
-  Wear OS doesn't bridge by default, and bridging itself goes through Google's
-  Wear OS app on the phone, so a degoogled phone gets none of it. Only the
-  "Snoozed until" notification reaches a watch on a Google phone. The options,
-  if this is picked up:
+  unscoped. A watch that shows and controls the phone's timers and next alarm
+  needs a phone-to-watch channel. The usual one is Google Play Services'
+  Wearable Data Layer (`play-services-wearable`), a proprietary service that
+  `docs/PRIVACY.md` §2 ("no analytics, tracking, advertising, crash-reporting
+  SDK or third-party service of any kind") and the F-Droid build rule out. A
+  channel of our own (a Bluetooth link run by both apps) would avoid it, at the
+  cost of building the transport. Today the ringing alarm and timer
+  notifications are foreground-service notifications, which Wear OS doesn't
+  bridge, so a watch doesn't get the ring. The options, if this is picked up:
   - **Standalone watch app**: its own timers, stopwatch and alarms on the watch,
-    no Play Services and no sync. Not blocked by anything; it just doesn't
-    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.
-  - **Bridge the ring**: let the ring and timer notifications reach a watch
-    (not ongoing, or a separate bridged notification), keeping in mind that a
-    dismiss challenge makes Dismiss open the phone's ring screen.
+    with no sync. No Play Services, but it doesn't control the phone, and there
+    is no F-Droid for watches, so it would ship through Play or sideloading.
+  - **Play-only companion**: the Data Layer confined to a Play Store flavour.
+    `PRIVACY.md` §2 would then need per-flavour statements.
+  - **Bridge the ring**: a separate, non-foreground notification for the ring
+    that Wear OS can bridge. A dismiss challenge would need a decision there.