Thinking mode and display changes are now tracked as their own telemetry reason

What

• Telemetry/event schemas gained thinkingMode and thinkingDisplay string fields, each validated against a fixed set of allowed values and defaulting to an empty string.
• The tracker that compares successive API request configurations now also flags thinkingModeChanged and thinkingDisplayChanged, alongside existing fields like effortChanged and extraBodyChanged.
• The request-cache invalidation-reason table gained thinking_mode_changed and thinking_display_changed entries, explaining why a cached prompt/request was dropped and re-sent.
• The turn-configuration-diff logger now reports "thinking mode changed" / "thinking display changed" (with previous/new values) alongside other turn changes like effort or model.
• The general status-diff helper used to compare snapshots also flags these two changes, but only once a non-empty thinking mode was already set on both sides.

Why

This lets Claude Code correctly explain and log why a request was rebuilt or a cached prompt was invalidated when you change thinking mode or thinking display, instead of leaving those changes unaccounted for in diagnostics and telemetry.