A spare session refuses claim_session when its flag settings were not applied

What

A program that drives Claude Code can start a spare process ahead of time with --await-claim and hand it to a user later by sending claim_session. Settings for that spare are sent with apply_flag_settings. The claim can now be refused if those settings did not take effect.

• The claim_session handler gets a new parkedSettingsRefusal callback. It returns claimRefusal() from the object that tracks parked settings.
• The claim is refused while an earlier apply_flag_settings is still unanswered: "an earlier apply_flag_settings is still unanswered; claim again once it is answered".
• It is also refused when the latest apply_flag_settings was refused, or when a flag-settings key would not be in force.
• The error reads settings_not_applied: ... - nothing was claimed; start the session with query().
• This applies only to the spare process started with --await-claim.
• The claim_session description now says to send an apply_flag_settings carrying the MCP and plugin keys ahead of the claim, and that refusing those settings also refuses the claim. Before, it said to send set_model, set_max_thinking_tokens and apply_flag_settings right behind the claim.
• apply_flag_settings now waits for a settle step tied to each request instead of a fixed sequence. Plugin-forwarding patches still use the plugin_forwarding_patch_refused path.
• The builder for the initialize payload takes one more argument.

Why

A host can no longer claim a pre-warmed session whose settings never took effect, so a session does not start with the wrong MCP servers or plugins. Hosts should send the MCP and plugin settings before the claim, and be ready to start with query() when the claim is refused.