NanVix blockedHosts overrides defaultPolicy=block

> ⚠️ **Security notice:** When reporting BSODs or security issues, **DO NOT** attach memory dumps, logs, or traces to GitHub issues. Instead, send them to secure@microsoft.com referencing the GitHub issue. For application crashes, include a Feedback Hub link if possible (open with Win+F, choose "Share My Feedback" after submission).

### Relevant area(s)
Windows

### Brief description of your issue

The NanVix backend enables host networking for a non-empty `network.blockedHosts` list even when `network.defaultPolicy` remains at its secure default of `block`. It then applies an allow-by-default blocklist, silently widening the requested network boundary and contradicting the meaning of `defaultPolicy=block`.

### Steps to reproduce
1. Run a NanVix sandbox with `network.defaultPolicy` omitted or set to `block`.
2. Add one entry to `network.blockedHosts`.
3. Attempt network access to a destination not in `blockedHosts`.

### Expected behavior

`network.defaultPolicy=block` remains authoritative. `blockedHosts` must not enable host networking to every unlisted destination; the backend should either preserve block-by-default semantics or reject the incompatible policy combination.

### Actual behavior

`host_networking_enabled` returns true whenever `blockedHosts` is non-empty, and the runner forwards the entries through `-block-host`; its validation explicitly ignores `defaultPolicy` when either host list is present. The generic boundary-relaxation audit also omits `blockedHosts`, so this backend-specific relaxation is not logged.