#910 App SDK ctx.checkpoint() promises exactly-once replay caching and delivers none in production

EARS SPEC: - When an app action calls ctx.checkpoint(step_name, func) and the workflow later resumes from a suspend or crash, the Highway app runtime shall return the cached result instead of re-executing func. - If the Highway app runtime cannot provide checkpoint caching on a given execution path, then the SDK shall not document that path as providing exactly-once semantics, and shall raise or warn rather than silently degrading. EVIDENCE (static, verified): - enterprise/apps/sdk/context.py:239-243 docstring: 'If the workflow resumes from a crash or sleep, the cached result is returned instead of re-executing the function. This is critical for ensuring exactly-once semantics.' - enterprise/apps/sdk/context.py:266-271: 'if self._is_ipc_mode: return cast(T, func(*args, **kwargs))' - executes locally, no memoization, no checkpoint written. - Apps ALWAYS run in IPC mode in production (enterprise/apps/executor.py:452-454 forks a child for every invocation), so the non-IPC branch that would call self._ctx.step() is unreachable in production. - Consequence: after a durable suspend (ctx.sleep / wait_for_event / request_approval), the action re-runs from line 1 and every ctx.checkpoint block re-executes. Only set_state values and explicitly checkpoint_name'd ipc_* calls survive. IMPACT: an app author who reads the docstring and wraps a non-idempotent side effect (charge, provision, send) in ctx.checkpoint gets it executed again on every resume. The API is documented as the safe way to do exactly that. Related: #907 (tiering - this caps how much can move into apps).