refactor: styles own their ringing tone directly (Pattern C)

Drop the injected AlarmSound Protocol and the wecker.Sound class. Each style
now owns its tone by using pygame directly; the runner owns only the audio
engine lifecycle (mixer init/quit), button sampling, and cleanup. This is the
seam for future styles that handle their own tone — a 'talk' style would just
import pygame and play speech, with no shared interface to extend.

- styles/base.py: AlarmStyle.__init__(set_led, music_file) + start() + update()
- styles/blink.py: start() loads+plays music via pygame.mixer.music
- styles/simple.py: owns its beep — synthesises a square-wave buffer in
  module (stdlib array+math) and plays it via pygame.mixer.Sound
- wecker.py: setup() brings up the mixer only; run_alarm constructs the style
  and guards start() with a clean log+exit on failure

Tests: a shared tests/conftest.py stubs RPi.GPIO/pygame in sys.modules before
any SUT import (order-independent, removes duplicated inline mocking); the
wecker mock_pygame fixture patches one fresh pygame mock into wecker + both
style modules so assertions see the same calls.

README: tone-ownership and plugin-contract updated.

styles/base.py

@@ -1,44 +1,26 @@
 from abc import ABC, abstractmethod
-from typing import Callable, Protocol
-
-
-class AlarmSound(Protocol):
-    """Audio capability injected into a style so it can own its ringing tone.
-
-    Styles stay free of pygame/GPIO imports (the API process imports them only
-    for name validation); the runner supplies a concrete implementation.
-    """
-
-    def play_music(self, path: str) -> None:
-        """Load and play a music file on an endless loop."""
-        ...
-
-    def play_beep(self) -> None:
-        """Play one short beep tone."""
-        ...
+from typing import Callable
 
 
 class AlarmStyle(ABC):
     """A pluggable alarm behaviour.
 
-    A style owns *its own ringing tone* (via the injected ``sound``) and
-    decides when the alarm stops and what the LED does. It never touches
-    hardware directly: ``set_led`` and ``sound`` are injected by the runner, so
-    styles stay import-safe in the API process (no GPIO/pygame).
+    A style owns *its own ringing tone*: it uses the audio engine (pygame)
+    directly and decides when the alarm stops and what the LED does. It never
+    touches hardware directly: ``set_led`` is injected by the runner, and the
+    runner owns the audio engine lifecycle (mixer init/quit). Styles stay
+    import-safe in the API process — ``import pygame`` does not initialise
+    audio, so the API can import styles just to validate names.
 
-    Lifecycle: construct once with ``set_led``/``sound``/``music_file``; call
-    ``start()`` to begin ringing (kick off the tone and initial LED); then call
-    ``update`` every tick. Return ``False`` from ``update`` to stop the alarm.
+    Lifecycle: construct once with ``set_led``/``music_file``; call ``start()``
+    to begin ringing (kick off the tone and initial LED); then call ``update``
+    every tick. Return ``False`` from ``update`` to stop the alarm.
     """
 
     def __init__(
-        self,
-        set_led: Callable[[bool], None],
-        sound: AlarmSound,
-        music_file: str | None = None,
+        self, set_led: Callable[[bool], None], music_file: str | None = None
     ):
         self.set_led = set_led
-        self.sound = sound
         self.music_file = music_file
 
     def start(self) -> None: