fix(voice): stop a tap meant to wake Aide from closing its microphone

[0dillon]

Waking was silent. The only sign a tap had landed was micStatus reading "waking up…", which is on screen, which is the one place these users cannot look. So the natural response to tapping and hearing nothing is to tap again — and the third tap completed a mute run.

The user asked Aide to start listening and heard "That's three taps, I'll stop listening now." The mic then stayed shut against every path that would have reopened it, which is exactly what the hold is built to do.

Two changes, because either alone leaves the trap open. Taps that arrive while Aide is asleep no longer count toward a run at all: while dormant, a tap means wake and nothing else. And waking now answers out loud, so there is a reason to stop tapping rather than a silence that invites more. Kept to two words — this fires on an ordinary tap, and a sentence would wear thin inside one session.

Separately, start() now republishes muted and dormant rather than only active. One VoiceEngine is shared across remounts while the provider's state is rebuilt from defaults each time it mounts, so a held microphone came back reporting itself as listening. A wrong status is worse here than no status: someone who cannot see the screen has no second source to check it against, and would go on talking to an Aide that had stopped listening.