refactor(core): remove inert maxServeErrors option (#278)

[momics]

Summary

maxServeErrors was documented as "consecutive accept-loop errors before the serve loop terminates (default 5)" and plumbed from the JS API through every adapter into core ServeOptions.max_serve_errors — but the accept loop never consumed it (#278).

Per maintainer decision, this removes the option entirely rather than wiring it.

Why remove instead of wire

In iroh, Endpoint::accept() returns Option (None = endpoint closed, already handled), so the only accept-loop error is a per-connection QUIC handshake failure. Terminating the serve loop on a run of those would let any peer kill a server with a short burst of connection resets — a trivial DoS — and directly contradicts the existing accept_loop_survives_connect_reset_flood resilience invariant (which requires the loop to survive exactly that). There is no safe systemic-error surface for the option to act on, so it was dead weight.

Changes

• Core: dropped max_serve_errors from ServeOptions (options.rs) and the serve_options_defaults assertion (endpoint.rs).
• Adapters (core→adapter ripple): removed the field from node (src/lib.rs + generated index.d.ts), deno (dispatch.rs), tauri (commands.rs + guest-js/index.ts), and iroh-http-shared (IrohAdapter.ts, serve.ts).
• Docs: removed from specification.md, tuning.md, server-limits.md.
• Untouched: tests/resilience.rs::accept_loop_survives_connect_reset_flood stays as the invariant.

No behavior change (the option was inert). grep confirms zero remaining maxServeErrors/max_serve_errors references.

Verification

npm run ci → All checks passed (fmt, clippy, rust/tauri/node/deno tests, interop). Build churn reverted (index.js codegen, deno.lock); package-lock.json clean. No version-field bumps.

Closes #278