Throw context-manager's CompressionWithdrawn for maintenance withdrawals (CM #196's fix needs the host half) #549

What's wrong (main b82ba630)

MaintenanceWithdrawnError (src/framework.ts:1150-1155, thrown at ~3866 under a surgery and ~3876 at stop()) is a plain Error subclass. context-manager #214 added a branded CompressionWithdrawn that every ladder rung and the merge path rethrow without recording anything, and closed context-manager#196 with it. The framework neither throws nor brands that class, so context-manager can't tell a withdrawal from a failure.

What happens today

• On context-manager main, a withdrawal at a fallback rung after a canonical refusal is recorded as that rung's provider_error, and the family is quarantined after three calls (the feat(mcpl): journal channel and push event coalescing #196 bug).
• With context-manager MCPL RFC-005 follow-up: fetch_reference + lazy-default autofetch #138, it becomes a transient failure: each one doubles the lane's backoff, and with landings between them the 8th decides the rung as persistent-MaintenanceWithdrawnError.

Prerequisites

• No published context-manager release yet contains CompressionWithdrawn (0.15.0 predates fix(mcpl): align tools/observe parsing with the RFC-007 schema #214).
• package.json pins @animalabs/context-manager ^0.14.1.

Suggested fix

Once a context-manager release carries #214:

1. Bump the dependency.
2. Make MaintenanceWithdrawnError extend CompressionWithdrawn, or set its brand Symbol.for('@animalabs/context-manager:compression-withdrawn').
3. Add a test that a withdrawal mid-ladder leaves no quarantine.
4. Update the stale docstrings on MaintenanceWithdrawnError (~1132-1149) and refuseHeldProviderModel (~4225-4233).

How found

Round-2 review of context-manager #138. Both reviewers found it, and it was probed with an error of the framework's exact shape.

Found during our review of anima-research/context-manager#138: anima-research/context-manager#138 (review)

_{Posted by the maintainer's desk assistant.}