fix(cli): headings name a project by its label; four small CLI fixes

[kevintseng]

Refs #409, #410 and #412. Each of them also has parts this PR does not touch, so none is closed here.

Five small user-visible fixes found by an independent dogfood pass on release 4.10.2, in one commit (fix(cli): headings name a project by its label; four small CLI fixes).

What changes for a user

• Headings name a project by its label, not its 32-character hash (The injected briefing prints the 32-hex project id repeatedly and the standard index repeats memories already shown #409). Decisions and direction for "memesh~2c0fe491888c8efb9a4894828bbc2733": now reads Decisions and direction for "memesh":. The same goes for the other headings of the briefing, the task-state lines, the durable-memory index heading and its empty-state line, the first-run banner and the lines memesh task prints. One rule owns it, projectLabel in src/core/work-topology.ts: it removes one trailing ~ plus exactly 32 lowercase hex characters and leaves anything else alone. The full id stays wherever it identifies data: project: tags, entity names, the project field of JSON and MCP results, --project, and the unread-message line, which tells an agent which project to poll. Still there: the titles the session-summary and pre-compact hooks stored (2026-09-22 memesh~…: edited 12 file(s)) contain the whole id and are printed as stored under Recent activity (see "Not in this PR").
• briefing --json no longer reports hasTaskState: true when the only state line is the unread-message reminder. It is now true exactly when a task-state line leads the block: the fresh state, the one-line stale flag, or the unreadable-record line. The CLI's "set the task state" hint reads it, so that hint now also appears beside the reminder on a project with a message waiting and no task state.
• memesh config get <key> exists (CLI inconsistencies: config get is missing, status says up to date on a newer version, briefing --index prints the framing #410). It printed unknown command 'get'. It prints the stored value as config list shows it (for briefing: what is stored, not the level in effect), or <key> is not set in config.json (exit 0; it says nothing about which value applies, because an environment variable can still override the default). An unknown key is refused in the same two lines as set and unset (exit 1); the three share one requireAllowedKey.
• memesh status no longer calls a newer install "up to date" (CLI inconsistencies: config get is missing, status says up to date on a newer version, briefing --index prints the framing #410). On 4.10.2 (a trial build on the next tag) while npm latest was 4.9.4 it printed Update check: up to date (fresh; latest 4.9.4) and an Update path: for @latest, a downgrade. It now says running pre-release version (4.10.2), npm latest is 4.9.4, as memesh doctor already did, and prints no update path. A newer install that is also deprecated, whose check only partly succeeded, or whose check could not run keeps its update path: only the "running pre-release version" line withholds it, through one shared predicate (showsPreReleaseNotice) that the status line and the trailer both use.
• memesh config list always shows the briefing level in effect and where it comes from (The effective briefing level is not shown anywhere, and no live journey runs at the default level #412): briefing: minimal (default), briefing: standard (config.json), briefing: full (env MEMESH_BRIEFING), or, for a stored or environment value that is not a level, briefing: minimal (default; the value in config.json is invalid: "banana"). It uses the same resolver the hook uses. With nothing stored it prints (nothing stored — all defaults) first.

Evidence

• npm run verify GREEN on the tree of the commit (tree 27d19998019b; 262 test files, 4529 tests passed, 9 skipped; the isolated suite, the packaged-artifact smoke and the dashboard e2e included).
• An independent verifier ran every fix on the built output of the base commit and of the first version of this commit, on throwaway homes: all five reproduce on the base and are gone on the commit, neighbouring states are unchanged, the fields that identify data keep the full id, and a sweep of the output of eight commands finds no ~<32 hex> outside the project field. The MCP briefing tool was checked through a real JSON-RPC call.
• Break-tests on the review fixes (string write-back, sha256 restored each time): making the status trailer ignore the deprecated and partial states turns the two new CLI tests red; taking the deprecated exception out of showsPreReleaseNotice turns exactly its truth-table row red; putting the old config get text back turns the two config get tests red.
• Reviews of the whole diff by three independent reviewers (fresh-eyes, code review, silent-failure), plus the verifier above and a read-only simplification pass. The first version drew PASS_WITH_CONCERNS, PASS_WITH_CONCERNS and FAIL. The FAIL had three blocking findings, all real, all fixed in this commit: config get said "the default applies" while an environment variable could override it; the update path was wrongly hidden for a deprecated or partly checked install (a regression this change had introduced); a docs sentence said "every stored key" although one stored key is not settable. Two of them (silent-failure and code review) then re-reviewed the fix: no blocking finding, every earlier finding closed, and the status predicate checked against the status chain over 384 state combinations (0 mismatches). The remaining findings of those two were wording, fixed in the final commit; the third reviewer's non-blocking findings are either fixed or tracked above.

Simplification pass

A read-only pass over the whole diff found two candidates, both applied: the API reference repeated the allowed-key list in prose (cut: it goes stale unchecked, and memesh config set --help names the keys), and config set / config unset carried a pure alias, const canonical = key (removed). Kept on purpose, each checked for a consumer: the sort in config list (a test asserts the key order), the label === '' guard in projectLabel (a test pins it), describeEffectiveBriefing (one caller, but no other copy of it exists), and the overlapping test assertions (each goes through a different entry point).

Not in this PR (tracked)

• The injected briefing prints the 32-hex project id repeatedly and the standard index repeats memories already shown #409: the standard index repeating memories the block already shows, and the stored hook titles that still carry the whole id (a comment there describes both ways to close it). CLI inconsistencies: config get is missing, status says up to date on a newer version, briefing --index prints the framing #410: the briefing --index framing and the replaced_history_count docs. The effective briefing level is not shown anywhere, and no live journey runs at the default level #412: no live journey runs at the default level.
• Update check wording: memesh update says "Already on latest version" on an install ahead of latest, and memesh status says "up to date" when latest cannot be parsed #414 (new): memesh update says "Already on latest version" for an install ahead of latest, and memesh status says "up to date" when latest cannot be parsed. Both pre-date this change.
• Session-start pool selection: commits crowd out decisions, and the hook and the briefing use different windows and scores #411, Imported memories and note-file memories are never injected into a session, and nothing says so #407, Memories tagged with a plain project name are invisible to hashed-identity sessions; nothing tells the user and the heal command is undiscoverable #408.
• Left with the full id on purpose: the stored fallback title of a task state (it is never rendered as prose), lesson names, and the dashboard.
• Known simplification: when the status line is "running pre-release version", memesh status prints no Update path: on any install channel. Only the npm-global channel would have been sent to a downgrade; keeping the hint for the others would need a test that can stand up a global npm install, which is not worth one line of output.