BE-021: classify semantics — exec bit ignored, baseline mismatch, nested .be dir floods unk

Three shared/classify.js correctness gaps:

classify.js:142 — wtEqBase ignores the EXEC bit: a chmod-only change (0644→0755) reads ok, so it can never be committed AND is silently reverted by a re-get (the mode never propagates).
classify.js:470 — classifyDir baselines on baselineTip() while classifyMerge uses curTip(), so ls:/lsr: and status DISAGREE about a file's state after a patch.
classify.js:77 — nested-repo pruning accepts an any-kind .git but only a REG-FILE .be, so a nested PRIMARY be worktree (whose .be is a DIR) is not pruned → status floods with unk rows for the whole nested tree.

From the 2026-07-07 be/ review (BE/REVIEW), CONFIRMED. Method Issues.

Input

git tracks the exec bit as the only mode distinction; wtEqBase comparing content-only drops it.
The classifyDir/classifyMerge baseline split means two views of "the same file now" answer differently.
.be can be a redirect FILE (worktree) or a store DIR (primary) — the prune must accept both, as it does for .git.

A chmod-only change is a committable mod and survives re-get; ls/lsr/status share one baseline; a nested .be-DIR repo is pruned like a .git one.

Repro-first per defect (chmod-only mod; post-patch ls-vs-status agreement; nested primary wt not flooding unk).