Codex live projector's usableInBandCwd should reuse sessionMetaCwd now that #466/LLP 0150 landed

[philcunliffe]

hypaware-core/plugins-workspace/codex/src/exchange-projector.js's
usableInBandCwd(cwd, ctx) (added by PR #474, head 50919416) inlines its own
copy of the non-blank-and-absolute cwd predicate:

if (cwd.trim().length > 0 && isAbsolute(cwd)) return cwd

PR #474's own body says this is deliberate and temporary: "the docstring names
sessionMetaCwd and says to unify them once #466 lands... Duplicating two
boolean checks was preferred over either blocking this fix on #466 or moving a
shared predicate into core in the same change that #466 is already moving code
around in."

#466 has since merged (1555f13), together with LLP 0150
("one reader for the Codex session_meta header"), which exports exactly this
predicate as sessionMetaCwd from src/core/codex/rollout_session_meta.js for
precisely this reuse case: "exported because the codex backfill folds
turn_context.cwd as a fallback for the same field into the same gate, and so
must answer the question identically instead of keeping a looser copy."
hypaware-core/plugins-workspace/codex/src/backfill.js, which sits in the same
directory as exchange-projector.js, already imports it:
import { sessionMetaCwd } from '../../../../src/core/codex/rollout_session_meta.js'.

LLP 0150 itself does not mandate this: its "Still outstanding" section
explicitly scopes the in-band cwd path out ("a different source with a
different trust story... tightening it is its own decision rather than a
consequence of this one"). So this is not a violated invariant, and it changes
no behavior today (both predicates are byte-identical: non-blank-after-trim AND
path.isAbsolute). But LLP 0150 exists specifically because two independent
copies of this exact rule have already drifted and shipped wrong twice (#453,
#459) in this codebase, and #474's own body names unification as the intended
next step once the dependency it was blocked on landed. That dependency has now
landed.

Ask: replace usableInBandCwd's local predicate with a call to
sessionMetaCwd, keeping the local wrapper only for the error_kind
(cwd_blank vs cwd_not_absolute) classification the shared predicate does not
expose (it can still call the two checks separately for logging while trusting
sessionMetaCwd's return value as the source of truth), and update
exchange-projector.js's docstring plus the llp/0083-codex-live-cwd-from-rollout.decision.md
bullet that currently describes this as still depending on an unmerged PR.

Non-blocking: filed as a follow-up, not a reason to hold #474.

[philcunliffe]

🤖 neutral: stuck on sequencing, not on the finding (blocked on PR #474 merging)

Relabelling this immediately after filing, because as filed it was not actionable.

Why

This issue asks that usableInBandCwd be consolidated with sessionMetaCwd. Verified just now:

git grep -c 'usableInBandCwd' origin/master   ->  ABSENT from master
git grep -c 'usableInBandCwd' origin/fix/issue-471
    hypaware-core/plugins-workspace/codex/src/exchange-projector.js:2
git grep -c 'sessionMetaCwd' origin/master
    hypaware-core/plugins-workspace/codex/src/backfill.js:3
    src/core/codex/rollout_session_meta.js:3

sessionMetaCwd is on master now (it landed with PR #466). usableInBandCwd is not: it exists only on fix/issue-471, the branch of PR #474, which is still open and currently CONFLICTING after #466 and #467 merged.

So with only neutral:fix, this issue reads as "a fix attempt is owed here now", and the next reconcile tick would have dispatched a worker to consolidate a function that does not exist on the target branch. neutral:stuck is the honest state until #474 lands.

This is the second time neutral has made this mistake

Issue #470 was filed the same way and corrected the same way. The rule is: a follow-up whose subject code lives only on an unmerged branch gets neutral:fix AND neutral:stuck, with the blocking PR named. The triage that filed this issue was given that rule explicitly, including a pointer to #470, and still applied only neutral:fix. Recording that here because the pattern is what matters, not this instance: the distinction is easy to state and evidently easy to miss, and nothing in the tooling enforces it.

How this unsticks

Merge PR #474. Once usableInBandCwd is on master, this becomes an ordinary low-priority neutral:fix issue and the maintenance reconciler picks it up normally. No decision from you is needed on the finding itself, only the merge.

The finding, restated

usableInBandCwd (on #474's branch) and sessionMetaCwd (on master) implement the same predicate: non-blank after trim, and path.isAbsolute. Verified equivalent during PR #474's review: same trim semantics, same absoluteness test, byte-identical return on success. Only the input type differs, plus the logging.

Consolidating is non-behavioural and low priority. LLP 0150 explicitly scopes the in-band path out of its own mandate, so this is not a violated invariant, just a duplication worth removing before it drifts. Duplication of exactly this kind, in exactly this area, is what issue #465 existed to fix, which is the reason not to leave it indefinitely.

[philcunliffe]

PR #474 is merged, so usableInBandCwd is on master now and this is an ordinary low-priority consolidation as described. No further decision needed - proceed as filed (keep the local wrapper only for the error_kind classification, update the docstring and the LLP 0083 bullet).