Make verified napplet artifact size policy configurable and bounded

[jodobear]

Problem

Current Uzel master 10520965b58cd52ae8d1592f9c7a2adca1c56d73 hard-caps every verified napplet /index.html at 512 KiB:

• crates/napd/src/runner.rs:34: MAXIMUM_VERIFIED_DOCUMENT_BYTES = 512 * 1_024
• LinuxRunner::confirm_napplet passes that constant to read_launched_document at lines 940-944.
• read_launched_document passes it to RuntimeController::read_verified at lines 1209-1215.
• crates/napd-protocol/src/lib.rs:28: MAX_ASSET_BYTES = 512 * 1_024
• DaemonState::stage_surface rejects larger verified HTML at crates/napd/src/server.rs:269-292; UnixClient::fetch_asset independently rejects it at crates/napd-protocol/src/lib.rs:625-629.

A valid single-file NIP-5D napplet larger than 524,288 bytes therefore cannot reach WebKit. This blocks large applications such as Rage of Empires, whose current browser distribution is approximately 60 MiB before napplet packaging.

This differs from #25: that issue covered NAP-RESOURCE response transport after a napplet had launched. This issue concerns loading the verified executable artifact itself.

Expected behavior

Keep artifact loading finite and policy-controlled, but do not tie its ceiling to the private control-frame size. Uzel should expose one explicit, bounded product/runtime artifact policy and apply it consistently across verified read, daemon staging, IPC transfer, and client reconstruction.

The policy must not become unlimited. It should reject unsafe or unsupported values early and preserve bounded memory, transfer cleanup, exact-build verification, and clear user-facing refusal.

Acceptance

• Artifact maximum is explicit and configurable at the Uzel product/runtime boundary, with a documented finite default and hard safety ceiling.
• Zero, overflow, inconsistent, and above-safety-ceiling configurations fail closed before launch.
• Verified read, daemon staging, transfer metadata, chunking, and client reconstruction enforce the same selected maximum.
• Artifact transfer remains chunked; it is not forced through one control frame or one runtime envelope.
• Rejection reports actual size and selected limit without leaving an active surface, transfer, or partial artifact.
• Tests cover exactly-at-limit, limit-plus-one, configured multi-megabyte success, interrupted transfer cleanup, and malicious total/chunk metadata.
• Real Tauri/WebKit acceptance loads and runs a valid large single-file napplet while preserving source binding and sandbox restrictions.
• Artifact-size policy is documented separately from NAP message/envelope and NAP-RESOURCE response limits.