#<sha>./path broken in size/blob/type
A path descent off a SPECIFIC rev — size:#<sha>./a.txt, blob:?<ref>./a.txt — never fires: new URI folds the whole <sha>./a.txt into the fragment (or <ref>./a.txt into the query), but the views read descent segments only from the URI path component, so the leading sha/ref is treated as the whole id and the ./path tail is dropped. Broken for short AND full shas alike (so unrelated to JS-082's {1,39} resolve gap). Surfaced verifying JS-082. Method: Issues.
jab size "size:#<commit40>./a.txt" returns the COMMIT's size (or
the cur-tip), not a.txt's; jab blob "blob:#<commit>./a.txt" likewise misses.
views/size/size.js:49-89 resolveObject: segs come from path.split("/"),
but for size:#<sha>./a.txt the URI gives path="", frag="<sha>./a.txt" — isHexish(frag) is false (the ./a.txt tail), so it falls through to the cur-tip branch; the #<hex>./path case at :67-69 is never reached.
views/blob/blob.js and views/type/type.js; only the bare
size:./a.txt (cur-tip descent, no query/frag) works today.
#<hex>./path descent (size.js:67) — so this is areal gap vs the intended contract, not a missing feature.
#<sha>./path and ?<ref>./path descend the named rev's tree to the leaf in
size/blob/type; bare #<sha> / ?<ref> keep returning the object itself.
trailing ./path within the frag/query slot; keep direct-sha behaviour intact.
<hexrun>(./|/)<path>, split off
the leading [0-9a-f]{1,40} (or the ref up to the first /) as the id and feed the remainder as descent segs; reuse one shared helper across the views.
test/hexviews cases for size:#<commit>./a.txt +
blob:?<ref>./a.txt (red), then green; re-enable the descopes in be-js-hexviews-full-sha.
jab URI parse: `new URI(
"size:#<40hex>./a.txt") yields path=[] query=[] fragment=a.txt, so views/size/size.js:66 isHexish(frag) is false (the ./a.txt tail) → falls through to the cur-tip branch; the #<hex>./path descent at :76-78` is never reached. Same in blob/type.