fix(subagent): fail fast on incompatible-model resume

Problem

Resuming a persisted Subagent can fail before it performs any work when the resumed call is served by a different model than the one that produced encrypted reasoning or compaction payloads in the child conversation.

Observed failure:

Your request contains encrypted reasoning or compaction content that was produced under a different model. Encrypted payloads can only be replayed to the endpoint that created them.

The current user-facing behavior presents this as a generic stream/provider failure after the resume attempt starts. The parent has no clear indication that the child must resume on its original model, or that it should start a fresh child instead.

Proposal

Make model affinity explicit for persisted/resumed subagents:

• persist enough provenance to identify the originating provider/model for encrypted replay material;
• reject an incompatible resume call before constructing/streaming the child, with a precise model-affinity error;
• either require the original model automatically or expose an explicit, safe fresh-context alternative;
• include the compatibility constraint in the model-visible resume guidance and API/tool validation;
• add regression coverage for resuming a child whose replay payload was produced by a different model.

Acceptance

• An incompatible-model resume fails deterministically before a provider stream request.
• The error identifies the original and requested model/provider without exposing sensitive payloads.
• A compatible resume remains unchanged.
• The model-facing result provides an actionable next step (use the originating model or start a fresh child).