[Bug]: Windows reports an occupied runtime locator directory as a host permission denial #5735

Preflight

• I searched existing issues and discussions for this behavior.
• This report is not an unpatched security vulnerability.
• The report and attachments contain no credentials or private/internal material.

Issue origin

Observed or reproduced in a real environment

LoopX version or commit

main 9e78309

Host or runtime surface

Other

LoopX area

Control plane (goals, todos, quota, scheduler, registry, runtime)

Problem

When the managed runtime locator is occupied by a directory on Windows, Path.read_text() raises PermissionError. The current locator reader maps that to runtime_host_permission_denied and aborts before the managed server can report the existing filesystem startup diagnostic. This misclassifies an occupied locator as a host access refusal.

The repository already handles locator publication failures through the shared typed startup envelope. The Windows directory-open case should reach that path and report io_permission_denied, while an actually unreadable regular metadata file should continue to report runtime_host_permission_denied.

Minimal reproduction

1. On Windows, create a directory at the managed runtime locator path.
2. Run a control-plane operation that asks the Effect runtime client to inspect or start the runtime.
3. Observe the startup error.

The windows-powershell job for PR #5722 reproduced the mismatch: test_locator_publication_failure_surfaces_safe_typed_startup_diagnostic[directory-io_permission_denied] expected io_permission_denied but received runtime_host_permission_denied. The relevant source on current main is unchanged at _read_info() for this path.

Expected behavior

An occupied locator directory should reach the managed server's startup envelope and produce the shared Windows filesystem diagnostic io_permission_denied.

Actual behavior

The client raises runtime_host_permission_denied before the managed server starts, so the user sees a host permission error instead of the filesystem diagnostic for the directory conflict.

Sanitized diagnostics

Current main: `9e783092231b6a7f4728569105f83a364a5f8bad`.
Observed in Windows CI: [PR #5722 windows-powershell job](https://github.com/loopx-project/loopx/actions/runs/37395841540/job/112075527762).
Local regression reproduction on macOS simulated Windows' directory-open `PermissionError` at the locator reader and exercised the production runtime request path.

Additional context

Related merged work: #5551 typed locator-publication diagnostics and #5644 host permission classification. This report covers the Windows directory-open failure in the Python locator reader before the managed server can publish its existing diagnostic.