context-restore: (1) misses checkpoints a /context-save wrote from a nested repo when restore runs in a non-git parent, (2) current-branch-first loads the superseded plan checkpoint of the main tree #3065

Both cases return an older checkpoint without any error. Tested on 1.91.32.0
(post-#3003 identity stamps and ROOT_DIFFERS).

1. Save in a nested repo, restore in a non-git parent.
Layout: mono/ is not a git repo; mono/pkg is a git repo with remote
git@gitlab.example.com:grp/sub/repo.git. A session started in mono/, worked in
mono/pkg, and /context-save wrote to the bucket of pkg
(SLUG=sub-repo-<hash>, PROJECT_REMOTE=gitlab.example.com/grp/sub/repo). After
/clear, /context-restore in mono/ resolved SLUG=mono, PROJECT_REMOTE='' and
presented an eleven-day-old checkpoint as the latest. The right one was found only
because a hook had logged the save call and a manual find over all buckets followed.
gstack-slug only walks up from pwd (_outermost_project_root); it never looks at
checkpoints below the cwd. Related, but different from #2163 (non-git dir, save and
restore disagree for the same dir) and #2649 (nested repo resolves to the outer repo).

Suggestion, smallest first: (a) when the cwd is not inside a git repo, or the newest
checkpoint of the cwd's bucket is older than a save event of this session, also scan
other buckets for checkpoints whose project_root: lies below the cwd and offer them;
(b) context-save leaves a pointer (project_root + bucket) in the bucket of the
starting directory.

2. Plan in the main tree, implementation in a ticket worktree: branch-first picks the plan.
Flow: plan checkpoint saved on master of the main tree; implementation continues in a
worktree of the same repo (branch feature/<n>-…), where a second checkpoint is
saved that completes most of the first one's Remaining Work. /context-restore in the
main tree (on master) applies the rule from #2052/#2054 and loads the master
checkpoint. The rule exists to stop sibling worktrees from shadowing a branch's own
save, but here the sibling worktree is the direct continuation (same repository,
worktree path below the main tree, same ticket in the title). Seen three
times in different repos; each time the newer checkpoint was noticed only because the
SessionStart context listed it separately.

Suggestion: in Step 2, when a checkpoint of another branch is newer, belongs to the same
repository and its worktree/title names the same task, show both and propose the
newer one as continuation instead of silently taking the branch match. context-save
could optionally write supersedes: <file> when it continues an earlier checkpoint.
Related: #2052/#2054 introduced the current ordering.

Relevant place: context-restore/SKILL.md.tmpl Step 1 (candidate ordering,
--classify-checkpoints) and Step 2; bin/gstack-slug _outermost_project_root;
context-save/SKILL.md.tmpl frontmatter.