SUBS-045: descended read views emit nav/hunk URIs WITHOUT the sub-mount prefix → hunk click-through resolves in the WRONG (super-repo) store DIS-058, read-side twin of SUBS-039

SUBS-039/LOG-002 taught the be/ JS READ views to DESCEND into a mounted sub when the query path falls there (jab log:be logs the sub's OWN history, correct). But a descended view still emits its per-row / per-leaf nav URIs STORE-AGNOSTIC — WITHOUT the descent prefix. The pager re-dispatches each nav URI as a fresh jab <uri> FROM ITS OWN CWD — the SAME base the original call used (ctx.repo == be.find(cwd), core/loop.js:269). So an emitted URI's path must be expressed RELATIVE TO THAT BASE, exactly like the original log:<path> arg; a bare commit:?<sha> names a sub object the base store can't resolve → dead nav. The quantity to prepend is NOT an absolute top-wt path but the DESCENT DELTA relative to ctx.repo — precisely the joinPrefix accumulation descendSub computes and THROWS AWAY. This keeps links cwd-INVARIANT: from the journal root the link must read commit:be?<sha>, but cd be && jab log: has base = the be sub itself, descends nothing, so the link must STAY commit:?<sha> — prepending be there would be WRONG. Worse still, the TARGET read views (commit:, blob:, tree:, size:) do NOT descend a <sub> prefix at all (sub-blind — only log learned descendSub), so even a correctly base-relative commit:be?<sha> won't round-trip yet. This is the READ-side twin of SUBS-039 (the state-verb path-delegation primitive): a descended read view must (a) emit URIs prefixed by the descent delta relative to ctx.repo, and (b) the target read view must DESCEND that prefix from the same base before resolving. Scope be/ JS; parent DIS-058; see Submodules, BRO-006; method Issues.

Input

Context

Goals

Constraints

WIP

Design decisions

TODOs

Blockers and bummers

Outcome

</content> </invoke>