Subflow child HITL holds do not appear in the parent run's context

[queso]

Problem

When a child flow invoked through kind: subflow reaches a HITL hold, the hold follows the child flow's own egress channels and hold_timeout_seconds. The parent station stays in flight and learns nothing. If the child's hold times out or the child halts, the parent attempt fails with a named reason and goes through the normal attempt cap (src/controller/executor.ts:4190-4192).

For the person who started the work, the ask appears somewhere other than the parent run's thread, or does not appear at all, and the parent then fails with a child-hold timeout.

Ask

Show a child's holds in the parent's context. The child's short list and prompt appear in the parent run's channel or thread, and answering them advances the child, which then advances the parent station.

This depends on the resume-on-reply work. Showing the hold is not enough unless answering it drives the composed run forward in one step. Without that, the caller still has to coordinate reply and resume across the parent/child boundary.

Design questions

• Channel inheritance: does the child post to its own egress, or does the parent's egress context override it so there is one thread per request? Parent context is the preferred default.
• Reply routing: a reply should not require the child's run id. It should resolve through the parent.
• Timeout: with holds shown in the parent's context, does a child-hold timeout still use a parent attempt, or does the parent inherit the child's on_timeout policy?

Acceptance criteria

• A parent flow whose subflow child reaches a pick hold posts the ask to the parent's configured egress.
• Answering that ask resumes the child, and the parent station completes without an attempt failure.