fix(wasm): add input size limits and panic safety to file ingestion

[danielewood]

Summary

WASM file ingestion lacks size limits and panic recovery in addFiles, risking OOMs and unresolved Promises on panics.

Underlying problems

1. addFiles and inspectFiles allocate make([]byte, dataJS.Length()) with no size cap, allowing large inputs to trigger OOM or GC pressure.
2. addFiles runs in a goroutine without panic recovery, while inspectFiles has explicit recovery.

Why this matters

In the browser, large inputs or panics can freeze the UI, crash the WASM module, or leave Promises unresolved, degrading the web app experience.

Evidence

• Unbounded allocation in addFiles: cmd/wasm/main.go:82-84.
• Unbounded allocation in inspectFiles: cmd/wasm/inspect.go:61-64.
• Panic recovery present in inspectFiles but missing in addFiles: cmd/wasm/inspect.go:44-48 vs cmd/wasm/main.go:66-67.

Acceptance criteria

• Enforce a reasonable max input size for both addFiles and inspectFiles (with clear error messages).
• addFiles uses panic recovery similar to inspectFiles.
• Tests or deterministic checks cover size limit behavior and panic recovery.

Suggested approach

• Introduce a shared const maxWasmInputBytes and check dataJS.Length() before allocation.
• Wrap addFiles goroutine body with a defer recovery that rejects the Promise.

Dedupe notes

Checked open issues #88–#92 and gh search issues "repo:sensiblebit/certkit" with relevant keywords; no overlapping issue found. Classified as new.

[danielewood]

Implemented in #105 and included in #110, now merged to main. Closing as complete.