Handle unknown network capacity and preserve VM limits

[sjmiller609]

Summary

• Mark failed network capacity discovery as source: "unknown" and skip host network admission enforcement instead of rejecting allocations against zero capacity. Explicitly configured host limits, including zero, remain enforced; allocation tracking continues.
• Initialize the HTB scheduler even when capacity is unknown. Attach new per-VM upload classes directly to the scheduler in that case, preserving their requested rate and burst ceiling without inventing a host-wide limit.
• With known capacity, ensure the shared parent class exists and reflects the current capacity. Preserve existing per-VM classes and filters during startup; capacity-mode changes apply to those classes when they are recreated.
• Keep numeric API fields as zero placeholders for unknown capacity. No schema/SDK changes or numeric infinity.

Tests

• GOTOOLCHAIN=go1.25.5 go test -race ./lib/network ./lib/resources
• GOTOOLCHAIN=go1.25.5 go vet ./lib/network ./lib/resources
• Ran the race-enabled network regression binary as root on an HTB-capable Linux kernel. The test creates a private network namespace and covers unknown capacity, transitions to/from known capacity, configured capacity updates, per-VM rates/ceilings, and preservation of classes/filters on repeated initialization.
• The same regression test fails against the previous commit, reproducing the missing-parent error.

The privileged network test skips in non-root runs. API compilation was attempted but blocked by missing embedded hypervisor, guest-agent, and Caddy binaries in the checkout. Full hypervisor integration tests were not run. This update has not been deployed.

[sjmiller609]

the better solution is to just use existing configuration for network capacity capacity.network