Support persistent session reminders/constraints separate from the TODO list

Problem

The TODO list is effective for task tracking, but during long-running multi-turn projects, there's a second need it doesn't serve well: persistent reminders and constraints that should remain visible to Claude throughout the entire session.

Today, the only option is to overload the TODO list for this purpose. That breaks down because TodoWrite replaces the entire list on each call — when Claude finishes a major milestone and clears completed TODOs, those persistent reminders get swept away with them.

These are fundamentally different things:

• TODOs are tasks with a lifecycle: pending, in progress, completed, removed
• Reminders/constraints are session-scoped context that should persist until explicitly dismissed

Overloading one tool for both leads to a lossy experience.

Use Case

In a long-running session across a large codebase, I might want persistent reminders like:

• Always reference /docs/architecture.md before making structural changes
• All new endpoints must follow the auth pattern in /src/middleware/auth.ts
• Do not modify the legacy billing module — it's frozen for compliance

These aren't tasks to complete — they're guardrails that should remain visible to Claude throughout the session regardless of what tasks get added or cleared.

Proposed Solutions

Option A: Separate reminders/constraints mechanism

A dedicated tool (e.g., RemindersWrite) with its own storage and display, purpose-built for persistent session context. Items are added and only removed by explicit user request. This keeps the TODO list clean for task tracking and gives reminders first-class support. Could appear as a distinct section in the status line.

Option B: Pinned flag on TODO items

Add an optional pinned boolean to TODO items. Pinned items survive list rewrites and are only removed on explicit user request. Lower-lift change, but conflates two different concepts in one tool.

Current Workaround

A CLAUDE.md instruction to prefix items with [PINNED] and never remove them works reasonably well, but it's a convention rather than a tool-level constraint — Claude can still accidentally drop them when rewriting the list.