Policy: should host return-value conversion failures trap (poison) like unbranded host throws? #118

Surfaced by the platform-class characterization work (#117; contracts/embedder-api.md §"Error model", §Resources pattern note).

Today the two host-bug classes at the import boundary diverge:

• an unbranded throw from a host import → Trap, instance poisoned (contract: "an unbranded throw from a host import is a host bug and becomes a trap");
• a malformed return value (fails lowering, e.g. native null where WIT says option<string>) → the conversion layer's TypeError naming the import, rejecting that call only — instance stays live. Pinned in runtime/tests/embedder/platform_class_test.ts ("option-limit" case).

Both are host bugs; the contract's rationale for trapping throws ("defensive wrappers unnecessary by construction") arguably applies to garbage values too. On the other hand, the per-call TypeError is loud, names the site, and leaves unrelated instance state usable — and platform-class bindings (the #117 pattern) make transient shape mismatches likelier, where poisoning is harsher.

Decision needed: keep the asymmetry (document it in §Error model as deliberate) or converge conversion failures onto the trap path. Either way the platform_class_test pin should then assert the chosen behavior with a contract cite rather than characterized behavior.

No urgency: current behavior is safe (no silent data), just asymmetric.