[Bug]: fcntl import breaks EverOS on Windows — server fails to start

[smile-xuc]

Area: src/everos

What happened?

everos server start fails immediately on Windows with ModuleNotFoundError: No module named 'fcntl'. The fcntl module is POSIX-only (Linux/macOS), so the unconditional top-level import in src/everos/core/persistence/locking.py makes the entire server unbootable on Windows — including everos --help.

Expected: server starts and memory_root_lock works on Windows.

Root cause: locking.py imports fcntl unconditionally at module level. The module docstring even states "Windows is not supported", but portalocker (cross-platform) is already a project dependency (pyproject.toml, used in infra/ome/engine.py for the same single-instance-guard purpose). So the cross-platform fix is small and low-risk.

Steps to reproduce

1. On Windows: git clone https://github.com/EverMind-AI/EverOS.git + uv sync
2. Run uv run everos server start
3. Observe the traceback:

File "...\src\everos\core\persistence\locking.py", line X, in <module>
    import fcntl
ModuleNotFoundError: No module named 'fcntl'

Even uv run everos --help fails, because importing the package pulls in locking which fails to import.

Environment

• OS: Windows 11 (10.0.26200)
• Python: 3.13.12
• EverOS: latest main
• venv managed by uv

Logs or screenshots

The traceback above is the entire failure — the process never reaches the lifespan startup phase.

Suggested fix (verified locally)

I have a working patch. Approach: a platform branch — keep native fcntl.flock on POSIX (zero behavior change), fall back to portalocker on Windows. Key points:

• import fcntl moved under if sys.platform != "win32".
• POSIX path unchanged: same os.open + fcntl.flock + LOCK_NB / BlockingIOError flow.
• Windows path: portalocker.Lock(...) with LOCK_EX | LOCK_NB, translating portalocker.LockException → the existing LockError so the public contract stays uniform.
• The companion test tests/unit/test_core/test_persistence/test_locking.py has the same fcntl problem in its child-process helper script; updated it to call the project's own memory_root_lock instead of a hand-rolled fcntl script, so the child process is cross-platform too.
• Verified on Windows: all 4 tests in test_locking.py pass after the patch; ruff check + ruff format --check are clean. The POSIX branch is untouched, so CI (Ubuntu) behavior is unchanged.

Happy to open a PR linked to this issue if it's welcome.