fix(wasm): bound retained guest memory for warm synchronous workers

[skhaz]

Problem

Warm synchronous WASM workers reuse one guest instance. Linear memory only grows, so an omitted recycling limit retains the worker high-water mark indefinitely. The existing per-function limits.max_retained_memory_bytes guard was opt-in and therefore did not protect default configurations.

Change

• an omitted limits.max_retained_memory_bytes now uses a 64 MiB per-worker recycling trigger
• an explicit 0 remains unlimited and survives JSON/YAML decode and encode
• a positive entry value remains the function-owned override
• the built-in trigger inspects after the first call and every 16 completed calls; retained_memory_check_interval can override the sampling interval
• memoryless workers stay warm through the explicit Instance.HasMemory primitive added in fix(runtime): expose safe instance memory presence wasm-runtime#14
• components use isolated module ownership only when recycling is enabled

There is no application-wide wasm.limits configuration and no new process-level policy. Aggregate pool/process memory budgets remain a separate concern.

Repro

On main, a one-page WAT guest growing two pages per call reached 4,001 pages after 2,000 calls and retained about 332 MiB of Go heap after GC. The existing explicit 1 MiB trigger kept the same workload at 17 pages and about 9 MiB after GC. This change makes the bounded behavior the default while preserving an explicit unlimited setting.

Verification

• make test-runtime passes with the race detector
• make lint passes with 0 issues
• focused WASM API, engine, function-manager, and boot tests pass
• JSON and YAML tests cover omitted, explicit zero, positive limits, and round trips
• memoryless, zero-page, default, explicit, component, add, and update paths are covered

The branch is rebased on current main and squashed to one commit.