default --block-private-networks for agent-driven examples (SSRF defense)

[staylor]

What & why

Adds a new Security section to SKILL.md and turns --block-private-networks on by default in every canonical command across MCP, CLI, and CDP. The flag already exists in the Lightpanda binary — this is a docs/defaults change, not a feature.

The threat model

Lightpanda executes page JavaScript. A skill specifically marketed for agent integrations (Claude Code, Openclaw, others — per the README) is going to feed it URLs that originate outside the agent's control: search-result links, redirects, page-internal fetch calls, embedded <iframe> srcs. Any of those can resolve to:

• localhost (services running on the dev/CI machine driving the agent)
• RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
• Link-local + cloud-metadata: 169.254.169.254 (AWS IMDS, GCP metadata server), 100.64.0.0/10

A malicious page can issue arbitrary requests to those addresses via JS-driven fetch/XMLHttpRequest, redirects, image srcs, etc., harvesting AWS instance credentials or pivoting into private networks. This is plain old SSRF — the only novelty is the agent context, which makes it more likely the user didn't manually vet the URL.

--block-private-networks is the kernel-level IP filter Lightpanda already provides for exactly this case: it inspects post-DNS-resolution destination IPs and rejects anything in private ranges, regardless of what triggered the request (page JS, redirect chain, subresource).

Changes

• New section "Security: block private networks for agent-driven use" between Install and "When to Use What", explaining the threat model in concrete terms (with examples like 169.254.169.254) and the recommendation.
• Flag added to: claude mcp add invocation, MCP JSON config args, lead CLI fetch example, all three follow-up CLI examples, and the canonical lightpanda serve command.
• --block-private-networks and --block-cidrs documented in the CLI fetch options list with brief descriptions and a back-link to the Security section.
• --block-private-networks documented in the CDP serve options list.
• One-paragraph callout under the canonical serve command explaining that CDP has the same SSRF surface as the MCP/CLI flows, with explicit guidance on when it's safe to drop the flag (driving the browser at private hosts you control: your own dev server, staging behind a VPN, etc.).
• scripts/install.sh: the final Run with: echo updated to match the new canonical command.

Tradeoff: when users want to hit private hosts

The flag is a runtime toggle, not a build option, so users with legitimate need (scraping their own internal dev server, staging behind a VPN, intranet documentation) just drop the flag and the docs explicitly call out where that's appropriate. --block-cidrs 10.0.0.0/8,-10.0.0.42/32 is also documented as a fine-grained escape hatch (block all of 10/8 except for one specific allowed host — the - prefix on a CIDR means "exempt from blocking", verified against the binary's own help).

Stack

Independent of #11 (install.sh fixes) and #12 (docs corrections); all three branch off main directly and can be reviewed/merged in any order.

If you'd prefer this PR to only add the Security section without changing the canonical commands' defaults, happy to scope it down. The defaults are the most opinionated part — the section + flag documentation in the options lists are pure additions and uncontroversial.