/model selection silently overridden (Fable 5.1 → Opus 4.8), likely a security-classification false-positive on a benign Wine game-compat task

## Summary

An explicit model selection made via `/model` was silently overridden mid-session. I selected **Fable 5.1** (and saved it as my default), but the session continued to run as **Opus 4.8**. I did not choose Opus 4.8 at any point.

## What I observed (verifiable)

- I ran `/model` and set the model to **Fable 5.1** (twice — the second time it was saved as my default for new sessions).
- Despite that, the session's own status line reported **"You are powered by the model named Opus 4.8."**
- So my explicit `/model` choice was not honored; the effective model was something I never selected.

## What I expected

`/model` is an explicit user choice. If the harness must route away from the selected model (for policy/classification reasons or otherwise), it should at minimum be **visible and explained** — not a silent override. Ideally the user's selection should be honored, or the user should be told *why* it can't be, with a way to opt back in.

## Suspected cause (my hypothesis — not confirmed from inside the session)

The session was a long, benign task: getting a **legally-owned game client (MapleStory TW) to run on Linux under Wine**. The work involved things a naive security classifier could easily flag:

- Binary-patching Wine's *own* DLLs (`kernelbase.dll`, `win32u.so`) to fix Wine compatibility bugs
- Reading/analyzing anti-cheat components (BlackCipher / NEXON Game Security) from logs
- Disassembly and socket/`WINEDEBUG` tracing
- Vocabulary like "bypass" — used **only** to state that bypassing anti-cheat was explicitly *refused*

None of this is offensive security. The task never touched credential theft, malware, exploitation of third-party systems, or anti-cheat circumvention (that was explicitly declined). If a security classifier is what triggered the model change, this is a **false positive** on legitimate software-compatibility / reverse-engineering-for-interoperability work.

I want to be precise: I can confirm the *override* (selected Fable 5.1, ran as Opus 4.8). I cannot confirm from inside the session that a security classification *caused* it — that is my inference based on the task content.

## Why this matters

Reverse-engineering and binary patching for **interoperability / getting owned software to run** is a mainstream, legitimate developer activity. Silently downgrading/overriding the user's chosen model on these tasks (a) breaks the explicit `/model` contract, and (b) penalizes benign work. At minimum the override should be transparent; ideally the classifier should not treat "make my game run on Linux via Wine" as a security threat.

## Repro

1. Start a session and use `/model` to select a model (e.g. Fable 5.1).
2. Do a task involving Wine DLL binary-patching + anti-cheat log analysis + disassembly.
3. Observe the effective model reported by the session become/remain a different model (Opus 4.8) than the one selected.

## Environment

- Claude Code, Linux (Ubuntu, kernel 6.8), interactive terminal session
- Model explicitly selected: Fable 5.1; effective model observed: Opus 4.8

Start by reproducing the /model selection flow in Claude Code on Ubuntu and compare the selected model with the session status line during the described task. No source file or test is named; done means the selected model remains effective, or any routing override is visible and explained to the user.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.