fix: allow background worker to start on Windows (fcntl ImportError, #89)

[haidrrrry]

Problem (issue #89)

service/server/worker.py imports fcntl at module top level:

import fcntl

fcntl is a Unix-only standard-library module. On Windows the import raises ImportError immediately, so the standalone background worker (python worker.py) cannot start at all. This matches the Windows fcntl failure reported in #89.

Fix

Make the POSIX file-locking backend optional and fall back to msvcrt on Windows for the single-instance lock:

• import fcntl guarded by try/except; on failure fall back to msvcrt, else None
• _acquire_file_lock uses fcntl.flock, else msvcrt.locking(LK_NBLCK), else logs a warning and continues without singleton enforcement
• _release_file_lock mirrors the same backends
• contention except broadened to (BlockingIOError, OSError) because msvcrt.locking raises OSError when the region is already locked

The other Windows-hostile calls in this file (os.nice, loop.add_signal_handler) are already wrapped in try/except and degrade cleanly, so no change is needed there.

Verification

Reproduced and verified with the fcntl import blocked to simulate Windows:

Scenario	Import	Locking
Native POSIX (real fcntl)	ok	acquire → second attempt blocked → release works
Windows (fcntl absent, msvcrt present)	ok (previously ImportError)	acquire via msvcrt, second blocked, unlock on release
No backend (fcntl + msvcrt absent)	ok	continues with a warning, no crash

On the unmodified file the same simulation fails with ImportError: No module named fcntl, confirming the fix.

Closes #89