docs(architecture): say the timer-vibrate copy runs alongside the boot pass

It runs in its own coroutine with no ordering against the engines, not ahead of them.

Refs #22

docs/ARCHITECTURE.md

@@ -1911,9 +1911,11 @@ alarm that should buzz the bed and a kitchen timer that should only beep are
 different questions. Until #22 a timer vibrated exactly when the alarm
 default did, so nobody's timers change on update: `SettingsPrefs.settleTimerVibrate`
 copies the alarm default into the new key once, from its own coroutine at
-startup (never ahead of the engines' pass), and from then on the two move
-apart. The key's own default is `true`, the alarm default's, for the moment
-before that lands; a failed copy is tried again on the next launch. Fresh
+startup, concurrent with the engines' pass rather than ahead of it, and from
+then on the two move apart. The key's own default is `true`, the alarm
+default's, for the moment before that lands (a timer that rings in that moment
+on the first launch after the update may vibrate once); a failed copy is tried
+again on the next launch. Fresh
 installs therefore start with timer vibration on, like alarms; telling a fresh
 install from an updated one reliably was more machinery than the default is
 worth, and the switch is one tap away.