fix(collaboration): distinguish delegation entrypoints and preserve canonical peer tasks - #4871

Peer activation, bound delegation and native child admission could contradict one another in the same planning packet: a blocked peer bundle returned before native admission, the first display row hid other tasks owned by that peer, and a successful runtime probe appeared as execution readiness.

This change scopes peer blockers to their entrypoint, preserves canonical task candidates, and allows independently admitted native work while retaining the peer diagnostic. Bound delegation now separates runtime_readiness from execution readiness and explicitly requires the existing delegation inspect preflight. Runtime visibility grants no new authority; the coordinator's selected Todo remains distinct from worker tasks.

Peer candidate/admission rules move into the existing TypeScript effect boundary; Python keeps normalization and assignment identity hashing. Large peer inventories use the existing signed full-decision detail path in TurnEnvelope instead of dropping tasks or expanding its budget. CLI Markdown now displays scope, state and blockers. The integration contract includes Chinese and English guidance.

Validation:

• 40 focused Python tests, including live quota → envelope → Turn planning, disabled capability isolation and Markdown readback.
• 30 TypeScript tests, including 50-task ready/blocked, top-level/nested peer projections and signature drift.
• Control-plane typecheck, Ruff, two existing orchestration integration smokes and diff checks passed.
• Source CLI agent-context --phase before_plan readback verified the new fields without launching workers. This source environment's provider availability differs from the installed runtime; this is projection validation, not a DSH/Ark launch qualification.
• Public boundary scans: zero errors. Two pre-existing unrelated Goal warnings remain.

Product entry points: CLI and managed planning projections change. Existing frontend settings edit the unchanged spawn policy/configuration owner, while Lark consumes its existing interaction user-channel projection; neither directly renders these orchestration fields, so no new UI controls or packaged frontend change is needed. No provider launch, live Goal authority migration or installed-runtime upgrade is included. Maintainer review required; do not self-merge.