#3016 serve: keepawake primes its daemon before the first acquire (a fast request could miss the hold)

本文

## Title
serve: keepawake primes its daemon before the first acquire (a fast request could miss the hold)

Issue: Resolves #

## Summary

`prevent_sleep` starts its worker thread lazily, on the first `acquire`. A request that finishes fast - acquire, then release, all before the thread exists - never reached the loop, so the transient `count > 0` transition was lost and Windows was not held awake for it. The daemon is now started up front, and `acquire` waits until the loop has signalled that it is inside, so no request can outrun the thread.

## What changed

- `serve/keepawake.py` - `_start()` is called at construction, so the daemon waits on the condition from the start; the loop sets `_primed` and notifies under the condition; `acquire` waits on `_primed` before it counts. No public API change, no change to the ON/OFF calls themselves.

## Extra Notes

**Related to #1901, not a duplicate of it:** that PR fixes the same race on the test side, by keeping the mock request generator open until the fake Windows call records ON. This one fixes it in the runtime, which is where a real fast request hits it. The two are complementary; #1901's fixture change is not included here.

**Measured on this PC (Windows, no model loaded, the real power API is not called):**
- `serve/test_keepawake.py`: 6/6 OK, including `test_held_while_busy_and_released_when_idle` and `test_service_holds_for_the_whole_request_including_early_close`.
- Off and non-Windows paths unchanged: `test_off_and_non_windows` and `test_default_service_has_none` pass.

**Not tested:** the real Windows power API (`SetThreadExecutionState`) - forbidden in these tests, as in the existing suite. No suspend/resume behaviour is claimed.

Default path untouched: `prevent_sleep` stays opt-in, and the ON/OFF sequence a held request produces is the same.