#3241 [TUI] serve: keepawake primes its daemon before the first acquire (a fast request could miss the hold)

Descripción

### Problem and result

`serve/keepawake.py` starts its daemon thread lazily. A request that finishes before the thread exists (acquire then release, a fast request) lost the transient `count > 0` transition, so the machine-sleep hold never engaged: the server answered the request and the PC could sleep mid-session.

After: the loop signals it has entered and `acquire` waits for that, so the first acquire can no longer race the thread start. Same root cause as the test-side fixture in #1901, fixed in the runtime.

### Related discussion

Closed in the 0.2.0-beta tracker reset; rebased on main and re-verified per the reset note. #1901 fixed the same race on the test side.

### Approach

The daemon loop sets an "entered" event as its first act; `acquire` waits for that event before counting, so the count>0 transition is always observed.

### Validation

Passed, rebased on 0.2.0-beta main (`e88ee39d`): `python -m unittest serve.test_keepawake` → 6/6 OK, exit 0. Windows 11, Python 3.15; no real power API called.
Not run: real suspend/resume on battery; CI.

### Limits

Windows keepawake path only; the fix adds a startup handshake, no change to the power API calls themselves.