[Feature Request] Distinct buzzer notifications for companion_radio

[jocasmark]

Problem

On buzzer-only devices like the T1000E, several distinct events all share UIEventType::ack, so the user can't tell them apart by ear:

• Sending an advert vs. receiving a message
• Enabling vs disabling setting (buzzer, GPS)
• Incoming message while the companion app is connected vs. disconnected

A notification rework seems already be considered (according to the comments in the code), so opening this for discussion.

Proposal

Give each user-facing action its own short, easily-distinguishable buzzer pattern for better user experience, using a consistent rule: ascending pitch = activation / positive, descending pitch = deactivation / negative, and the number of notes encodes what was toggled.

Action	Pattern
Buzzer on	3 ascending beeps
Buzzer off	3 descending beeps
GPS on	4 ascending beeps
GPS off	4 descending beeps
Advert sent	distinct melody
Incoming msg (disconnected)	message melody
Incoming msg (connected)	quieter melody (app already shows it)

This avoids growing the UIEventType enum with one entry per setting the count/direction convention scales as more toggleable settings are added.

Also fix a small UX bug (?): when the user mutes via UITask::handleButtonTriplePress(), the confirmation tone is silenced by its own action. Hold mute until the buzzer finishes:

notify(/* disable tone */);
while (buzzer.isPlaying()) buzzer.loop();
buzzer.quiet(true);

Questions

1. Does the "N ascending/descending beeps" convention fit the planned notification rework, or would you prefer one UIEventType per setting?
2. If the convention is preferred, should the count-setting mapping live in AbstractUITask.h (a small table) or be passed as a parameter to notify()?