docs(permissions): correct the network pattern form

[wasaybuilds]

Follow-up to #1884, where network rules were reported as inert in both directions. The rules are evaluated; they just never match.

• Network resources are built as URIs before the check — format_tcp_resource gives tcp://{host}:{port} for fetch/http/listen, format_dns_resource gives dns://{hostname} — and permission_resource_matches globs the pattern against that whole string with permission_glob_matches, where a single * does not cross /.
• permissions.mdx said a network pattern is "a host (or host:port)", and the shipped allow-one-host example used patterns: ["api.example.com"]. Neither form can ever match, so a documented allowlist denies everything and a documented blocklist permits every host.
• Documents the URI form, fixes the example to tcp://api.example.com:* / dns://api.example.com, and adds a kernel test pinning the semantics — the existing network-pattern coverage only uses the URI form, which is why CI stayed green while the documented form was broken.

Matcher behaviour against tcp://api.example.com:443, verified by porting permission_glob_matches byte-for-byte to JS and running the matrix:

tcp://api.example.com:443   yes    literal
tcp://api.example.com:*     yes    the * never has to cross a /
api.example.com             no     literal mismatch at index 0
api.example.com:443         no     same
*                           no     single * halts at the / in //
**                          yes    crosses separators

This only corrects the documentation to describe what the matcher does. If you would rather the matcher accept a bare host / host:port — which would make every policy written from the old docs start working — that is the alternative fix and I am happy to send it instead; I left the permission matcher alone since it is the security boundary.

I could not run cargo test locally (no Rust toolchain on this machine), so the added test needs CI. Every assertion in it was checked against the ported matcher first.