🎙️ task - fix: introspection crashes on an input schema that carries a transform

[ehm-a-beaver]

🦫🎙️ dispatch to foreman

💧 task enqueued
   ├─ priority = ?
   ├─ yieldage = ?
   └─ leverage = ?

title
fix: introspection crashes on an input schema that carries a transform
description

.what

introspection must not crash when a consumer declares an input schema that carries a zod .transform().

.why

the two behaviors are each covered in isolation and never crossed, so the gap is invisible to the suite:

• case6 (genLambdaEndpoint.forAskEndpoint.test.ts:194-232) proves that an input schema with a .transform() is a SUPPORTED, tested feature
• case7 covers introspection — but only with a transform-free schema

so a consumer who adopts the tested feature and then deploys hits a crash the suite never sees. the blast radius is not one handler: introspection is service-wide.

.acceptance

• a handler whose input schema carries a .transform() can be introspected with no crash
• coverage CROSSES the two dimensions. the gap exists precisely because they are only ever tested apart, so a fix that repairs the crash without a crossed test leaves the same blind spot

.provenance — read the honest limits

surfaced mid-vision by the mechanic on the feat-input-only-validation-and-hydration bound, and flagged OUT rather than absorbed, since it sits outside that pr (rule.require.one-pr-per-worktree).

• verified by the seeder: case6 exists at :194-232 and does exercise .transform()
• NOT verified by the seeder: the crash path itself. treat the crash as the reporter claim, and reproduce it before you repair it

.the HOW is yours

per rule.forbid.prescribe-how-on-dispatch, .what / .why / .acceptance are authoritative. all else here is ground, never instruction.