updated docs/CLAUDE.md to correctly reflect checkpoint id linking

[Soph]

This explains better how the id in Entire-Checkpoint or Checkpoint is used in our codebase.

[Copilot]

Pull request overview

Updates documentation to clarify how checkpoint IDs link user commits to metadata stored on the entire/sessions branch.

Changes:

• Documented the checkpoint ID format, sharded storage path, and bidirectional lookup workflow.
• Updated CLAUDE.md commit trailer docs to describe checkpoint linking across both strategies.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
docs/architecture/sessions-and-checkpoints.md	Adds an architecture section describing checkpoint ID linking, storage sharding, and lookup flow.
CLAUDE.md	Updates developer docs on checkpoint ID linking and commit trailer expectations for both strategies.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The “Manual-commit” checkpoint ID generation is documented as happening during condensation (post-commit), but in the implementation the ID is generated (or reused) in the prepare-commit-msg hook before the commit is created (see cmd/entire/cli/strategy/manual_commit_hooks.go, where paths.GenerateCheckpointID() is called in PrepareCommitMsg). Please update this section to reflect that manual-commit IDs originate in prepare-commit-msg (and may reuse LastCheckpointID when splitting work across multiple commits).

Suggested change

	- Manual-commit: Generated during condensation (post-commit hook)
	- Manual-commit: Generated (or reused from `LastCheckpointID` when splitting work across multiple commits) in the `prepare-commit-msg` hook before the commit is created

[Copilot]

This describes the entire/sessions commit subject as always Checkpoint: <id>, but task checkpoints use a custom commit subject (while still including a Checkpoint: <id> line in the message body; see cmd/entire/cli/checkpoint/committed.go:buildCommitMessage). To avoid misleading readers, consider wording this as “commit message contains Checkpoint: <id>” and note that task checkpoints may have a different subject line.

Suggested change

	3. **Commit subject** on `entire/sessions`:
	- Format: `Checkpoint: a3b2c4d5e6f7`
	3. **Commit message** on `entire/sessions`:
	- Contains a line: `Checkpoint: a3b2c4d5e6f7`
	- Task checkpoints may use a different commit subject, but still include this `Checkpoint: <id>` line in the message body

[Copilot]

The manual-commit strategy doesn’t generate the checkpoint ID “when condensing”; it generates (or reuses) the ID in the prepare-commit-msg hook before the user commit is created (see cmd/entire/cli/strategy/manual_commit_hooks.go, which calls paths.GenerateCheckpointID() in PrepareCommitMsg). Please update this bullet so the timing/source of the ID matches the implementation.

Suggested change

	1. **Generated once per checkpoint**: Either when saving (auto-commit) or when condensing (manual-commit)
	1. **Generated once per checkpoint**:
	- **Auto-commit**: Generated when saving the checkpoint.
	- **Manual-commit**: Generated (or reused) in the `prepare-commit-msg` hook before the user commit is created.

[Copilot]

Entire-Task-Metadata is not a trailer key used in the codebase. Task metadata trailers use Entire-Metadata-Task (see cmd/entire/cli/paths/paths.go:MetadataTaskTrailerKey and FormatShadowTaskCommitMessage). Please rename this trailer in the docs to the correct key to avoid sending readers to a non-existent trailer.

Suggested change

	- `Entire-Task-Metadata: <path>` - Path to task metadata directory (for task checkpoints)
	- `Entire-Metadata-Task: <path>` - Path to task metadata directory (for task checkpoints)