feat(timers): give timers their own vibration and gradual volume

Timers vibrated by the alarm vibration default and never ramped. Both are
now the timers' own app-wide settings, next to the default timer sound in
Settings > Timers: a Vibrate switch and the same Gradual volume picker
alarms use. Timer.resolveSettings reads them instead of the alarm default
and the old TimerRing.RAMP_SECONDS constant.

A fresh install starts with timer vibration off, as Google Clock does, and
no ramp. An existing install keeps what its timers did: a one-shot DataStore
migration writes the new key from the alarm vibration default before the
first read, so nobody's kitchen timer silently stops buzzing on update. A
fresh install is told apart by an empty store (anything that has run once
has written its boot id); the migration writes the default there too, so it
never runs twice.

Backups carry both new fields. A file without them restores the alarm
vibration default as the timers' (what that install's timers did) and a
flat ring.

Silent plus vibration off still signals: Silent gives the player no
sources, and its onSilenced callback starts the vibrator whatever the
setting says. The settings row says so.

Fixes #22

docs/ROADMAP.md

@@ -316,7 +316,8 @@ Elapsed-realtime anchored.
   per-timer vibrate, volume-ramp or dismiss-challenge overrides (`timers` has
   one nullable settings column and four more would be a schema change), no
   "stop all" when several timers are expired, no undo after a delete (traded for
-  a confirmation, as with alarms), no ramp on a timer's ring, no presets
+  a confirmation, as with alarms), no ramp on a timer's ring (since added as
+  an app-wide timer setting, #22), no presets
   management screen and no editing of `default_timer_duration_millis` or
   `default_timer_ringtone_uri` (M10's settings screen). `TimerSnapshot.anchorIsStale`
   is still not surfaced in the UI. Of `AlarmClock`'s intent contract only the