Refusal Fallback Tracking Improved

The internal mechanism for tracking model refusal fallbacks now carries additional state across requests. Two new session-level fields were added:

• refusalFallbackHeaderArmed — indicates the fallback header should be sent on the next request
• refusalFallbackLatchOriginRequestId — records the original request ID that triggered the fallback

When the armed state is active, outgoing API requests now include new HTTP headers:

• x-cc-fallback-latched-by — the request ID of the original triggering request
• x-cc-fallback-from-model — the model that refused
• x-cc-fallback-category — the refusal category
• x-cc-fallback-trigger — what triggered the fallback
• x-cc-original-request-id — original request correlation ID

The pZp helper that searches message history for refusal fallback records was refactored to return the full record instead of a pre-filtered subset, enabling richer downstream handling. The XNt function is now called at three points in the main request loop (interactive, forked, and background sessions) to rearm the fallback header when applicable.