bug(setup): --protocol=slim silently no-ops when the installed Claude Code plugin predates the hook guard

[neuralabmarketing]

📋 Pre-flight Checks

• I have searched existing issues and this is not a duplicate
• I understand this issue needs status:approved before a PR can be opened

📝 Bug Description

engram setup claude-code --protocol=slim persists the mode and every signal reports success, but the static protocol prose keeps being injected on every session start when the installed plugin predates the hook guard (plugin 0.1.1).

The guard that consults engram protocol-mode lives in plugin/claude-code/scripts/session-start.sh. A binary at ≥1.19.0 paired with a plugin at 0.1.0 satisfies the documented floor (binary ≥1.4.0) while nothing in the actual injection path honors the mode. There is no warning at any point and no engram doctor check for the skew, so slim can be "on" for weeks with zero effect.

On this machine the mode was set 2026-07-09 and the no-op was found 2026-07-30 — 21 days of full prose while engram protocol-mode claude-code answered slim.

🔄 Steps to Reproduce

1. Install engram ≥1.19.0 (Homebrew) with the Claude Code plugin still at 0.1.0 — i.e. a plugin marketplace clone that predates plugin 0.1.1.
2. engram setup claude-code --protocol=slim → succeeds, no warning.
3. cat ~/.engram/protocol-mode.json → {"claude-code": "slim"}
4. engram protocol-mode claude-code → slim
5. engram doctor → 4 checks run, none about protocol mode or plugin version.
6. Start a new Claude Code session and inspect the SessionStart additionalContext.

✅ Expected Behavior

Either the mode is honored, or the user is told why it isn't. Any one of these would close the gap:

• engram setup --protocol=slim prints the minimum plugin version required for the mode to take effect;
• an engram doctor check compares the installed plugin's hook against that floor — the diagnostic surface and its --check CODE selector already exist;
• the plugin floor is documented in the --protocol help text and release notes, next to the binary floor.

❌ Actual Behavior

## Engram Persistent Memory — ACTIVE PROTOCOL is still injected in full — 1,694 bytes measured — on every session start. No warning from setup, no signal from protocol-mode (it prints slim, which is true of the persisted mode but not of the effective behavior), no doctor finding.

Operating System

macOS (Darwin 25.5.0)

Engram Version

1.19.0 (Homebrew) · Claude Code plugin 0.1.0

Agent / Client

Claude Code

📋 Relevant Logs

$ engram protocol-mode claude-code
slim

$ cat ~/.engram/protocol-mode.json
{"claude-code": "slim"}

$ engram doctor
Engram Doctor: blocked
Checks: 4 ok=1 warnings=2 blocked=1 errors=0
    (findings are about session/project naming drift — no protocol or plugin check exists)

# SessionStart additionalContext still opens with:
## Engram Persistent Memory — ACTIVE PROTOCOL

💡 Additional Context

The archived spec for the feature (openspec/changes/archive/2026-07-08-setup-protocol-flag/ARCHIVE-REPORT.md) documents the binary-side floor — protocol-mode returns slim only when the persisted mode is slim and the binary is ≥1.4.0 — and describes the guard as shipping with "version-pinned plugin hooks". The inverse skew, new binary with old plugin, isn't covered. It's also the easy case to fall into, because brew upgrade engram and /plugin update engram are independent actions with no cross-check between them.

Not a blocker — /plugin update engram fixes it. Filing because the failure is silent and looks cheap to surface.