Fix Serena MCP context, then decide whether to keep Serena at all

Narrowed. The original issue listed six tasks, four of which were phrased as things to
"consider" (modes, memory prompting, decision trees). Those are dropped. What remains is a
five-minute configuration fix, followed by an actual decision about whether Serena earns its
place - which is the question worth answering, and which cannot be answered fairly while the
configuration is wrong.

## 1. Fix the context (small, do first)

`ERIC/.mcp.json` currently specifies `--context ide-assistant`. **That context no longer
exists.** Serena ships these:

```
agent antigravity chatgpt claude-code codex copilot-cli
desktop-app ide jb-ai-assistant jb-copilot-plugin junie
oaicompat-agent vscode
```

`ide-assistant` was evidently renamed to `ide` upstream at some point after this workspace was
configured. Meanwhile `claude-code` exists and is purpose-built for this client.

Diffing `claude-code.yml` against `ide.yml`, switching gains:

- `search_for_pattern` added to `excluded_tools` (it duplicates the built-in search).
- A materially different prompt, which explicitly directs the agent to prefer Serena's
*editing* tools and warns that built-in edit tools will refuse edits to files that were read
through Serena. That is a real failure mode, not a stylistic preference.

Change:

```json
"--context", "claude-code",
```

Note that `ENABLE_TOOL_SEARCH=true`, suggested in the original issue, is now likely redundant:
Claude Code defers MCP tool schemas itself, so Serena's tool descriptions are not loaded into
every request.

## 2. Then decide whether to keep Serena

The genuine question, and worth answering deliberately rather than by drift.

**The case against, honestly stated.** The main historical objection was context cost - every
connected MCP server's tool descriptions riding along in every request. That objection is now
largely obsolete in Claude Code specifically, because tool schemas are deferred. What is left
is a weaker but fair argument: Claude Code's built-in search and editing have improved, and if
symbol-level navigation were essential, it would plausibly be built in.

**The case for, measured against this codebase.** Excluding vendored and generated code:

| Repo | LOC |
|------|-----|
| smartem-decisions | 22,496 |
| smartem-frontend | 13,620 |
| smartem-devtools | 10,998 |

The common rule of thumb is that semantic tooling starts paying somewhere above ~20k lines, so
these repos straddle the threshold. But total lines is the wrong measure - individual file size
is what determines whether whole-file reading is wasteful, and the distribution here is
lopsided: `api_server.py` is 3,051 lines, `MockDashboard.tsx` 1,437, `fs_parser.py` 1,276,
`consumer.py` 1,267.

The workload also matters. Recent work has been greenfield front-end development, where
symbol-level navigation earns little. Upcoming work is the opposite: changes that touch the
prediction weight tables across `update.py`, `initialise_prediction_model_weights.py` and
`consumer.py` at once, and event-contract changes requiring every consumer to be found. Those
are cross-file symbol operations, which is where this class of tool actually pays.

## How to decide

Not by another configuration change. Fix the context, then run one genuinely
refactor-shaped task with Serena and one without, and compare. A decision either way is a good
outcome; leaving it configured-but-unused is the only bad one.

If the decision is to drop it, the cleanup is: remove the server from `.mcp.json`, remove the
`prefer-serena.py` PreToolUse hook, and remove the Serena guidance section from `CLAUDE.md`.