Prompt-error absorption is content-blind: any tracked missing node absorbs any missing_node_type rejection

## Problem

`isMissingNodePromptErrorAbsorbed` (missingResourceAbsorption.ts) absorbs a `missing_node_type` prompt error whenever *any* missing node is tracked — it never checks whether the tracked types explain the type the backend actually rejected. The validation-error path correlates node id + input name + received value per candidate; the prompt-error path is a bare boolean.

Failure scenario: the backend restarts mid-session without a custom node pack, so it rejects type Y while the frontend still has Y registered (the queue-failure rescan checks `LiteGraph.registered_node_types` and finds nothing new) and separately tracks missing pack A. The prompt error naming Y is absorbed into pack A's card: `hasBlockingError` goes false, the "Blocked last run" pill lands on A, and installing A cannot fix the run. Y's name survives nowhere except the absorbed error's free-text message.

## Why it is not a quick fix

`PromptError.extra_info` carries only an optional `input_name`; the rejected type exists only in free text. Correlating requires either a structured field from the backend (preferred) or fragile message parsing.

## Suggested direction

Absorb only when at least one backend-rejected type intersects `missingNodesStore.missingNodesError.nodeTypes`, falling open to the red prompt row when they cannot be correlated. Needs a structured `rejected_node_types` (or similar) on the error payload.

Found during the multi-agent review of #14440.

Start in missingResourceAbsorption.ts, then trace PromptError.extra_info and the backend prompt-error payload to determine where rejected_node_types can be carried. Verify that only an intersecting type is absorbed and that uncorrelatable errors remain visible, with regression coverage for the Y-versus-A scenario.

Written by the indexing model from the issue text.