Do not autoplay audio dweets

We can detect an audio dweet if:
- It has been tagged #audio
- It contains code `Audio` or `SpeechSynthesis` or ...
- (It looks like it has a compressor, and the uncompressed code contains the above)
But just the hashtag would get us 99% of the way

Behaviour: An audio dweet should just start off paused. There will be a 'Play' button the user can click if they want to start the dweet running.

Optional extra:
- A 'Pause' or 'Stop' button that can stop all started audio.
One way to achieve this might be to override the `Audio` and SpeechSynthesis` constructors with our own functions that call the original functions, but also keep a copy of the constructed object in a global array, so that we can stop them when the button is pressed.
This might also be an advantage when someone is editing an audio dweet. When they change the dweet, our reset function can stop all the existing audio output, to provide a clean slate for the new version.

Start by locating the dweet execution and reset flow, then trace how #audio tags and playback controls are handled. Implement the required paused initial state and user-triggered Play action; treat global audio stopping and reset cleanup as optional. Done means audio dweets no longer autoplay and can be started through the provided control.

Written by the indexing model from the issue text.