session tokens: carry candidate-set completeness through both selection paths

ResolvedSession.Incomplete reached session current and session list but not session tokens, which drops it on both of its selection paths — and this is the command where losing the right session costs the most: the output is not a bare ID but per-session token figures plus recommendations to act on, in --json and --agent-brief as well as human mode.

The two paths lose it differently, which is why both needed work rather than a warning bolted onto one. The default path resolves the caller, where a lost candidate hides a nearer owner. --current goes through FindMostRecentSessionInCurrentWorktree, which read the lossy listing and returned a bare ID, so it could not have reported anything — and "most recent" is a comparison, so a listing short one entry can be short the winner. It now returns a ResolvedSession, which also removes the hand-assigned ResolutionWorktree at its call site and lets one warning cover both branches instead of the weaker path being the silent one.

Printed before the not-found return, for the same reason session current does it: "No active session found in this worktree." over a store that could not be read fully is the misreading, not the answer. On stderr, so both machine-readable modes stay parseable.

Six subtests cover selection path × output mode. Reverting the print fails all six; reverting only FindMostRecentSessionInCurrentWorktree to the lossy listing fails exactly the three --current ones, so the halves are independently pinned. Fixing them surfaced that makeSessionState sets neither WorktreePath nor LastInteractionTime, which are the two fields --current filters and ranks on, so a fixture built from it selects nothing on that path.

withHookSession still ignores the field, deliberately and now documented: it stamps a log field rather than selecting or acting on a session, and the store's own per-skip Warn already lands in the same log.