Fix #129: enforce MaxClientJsVarBytes on each browser write

[linkdata]

Fixes #129.

Problem

MaxClientJsVarBytes did not bound a non-PathSetter JsVar after its normal initial render. The only cap check lived in JsVar.JawsRender, but a normally rendered JsVar is never rendered again. A browser could therefore append one slice element per Set write and keep growing server-side state.

Fix

Enforce the cap in the client input path while keeping the common path O(1):

• Seed jsonBytes with the exact JSON length produced by the initial render.
• Add the length of each raw client-write payload to that approximate count, including rejected appends that still grow a slice.
• When the approximation crosses MaxClientJsVarBytes, use json.Marshal once to calculate the exact current length. Reset the approximation to that length when it remains under the cap; otherwise abort the request with ErrJsVarTooLarge.
• Use a subtraction guard for the boundary check so the approximate count cannot overflow on 32-bit or 64-bit systems.
• Treat an exact-size marshal failure as a failed size check: return ErrJsVarTooLarge, abort the request, and retain the underlying marshal error in the cancellation cause.
• Format the cancellation cause and cancel the request after releasing JsVar.setMu and the caller-provided value lock.

This deliberately does not duplicate encoding/json sizing rules. Exact JSON work happens only when the raw-byte approximation looks too high.

Programmatic JawsSetPath writes remain trusted and uncapped. PathSetter values remain exempt because they enforce their own path and size policy. The render-time check remains for values already over the cap at initial render.

Tests and benchmark

Regression coverage includes:

• valid, zero-value, and rejected append floods;
• raw client-payload accumulation and exact-size reconciliation;
• integer-overflow-safe boundary detection;
• fail-closed exact marshaling without leaking handler-control errors;
• request cancellation after internal locks are released;
• PathSetter, disabled-cap, and server-write exemptions;
• Linux/386 test-binary compilation.

BenchmarkJsVarClientWrite remains as the O(1)-per-write regression guard. Six-run benchstat comparison against the previous PR head (-benchtime=300ms -count=6) is statistically unchanged:

                              previous   final
SmallState                    883.6 ns   882.9 ns
LargeState                    892.9 ns   883.9 ns
Bytes/op                      272        272
Allocations/op                12         12

Verified with go test -race -count=1 ./..., go vet ./..., staticcheck ./..., golangci-lint run ./..., gosec ./..., gofumpt, go build ./..., and Linux/386 test compilation.