reserve 内手柄在当前服务端实现下不可达

第 3 步人工验证时发现：点遍所有道路都看不到灰色（不可拖）手柄。经实测确认这是正确行为，不是漏测。

实测数据

test/fixtures/fengshu-er-road.osm，24 条方向道路、32 个 reserve：

road handles        : 126
road NOT editable   : 0
with disabledReason : 0
junction handles    : 96   （JunctionTools 所有，主地图已过滤）

makeRoadHandles() 里 editable: false 的唯一来源是 unavailable：

const start = Math.min(1, startReserve);
const end = Math.max(0, 1 - endReserve);
const unavailable = start >= end;

而 junctionReserves() 给每端的保留区比例有硬上限：

const fraction = Math.min(0.45, cutback / length);

于是 startReserve ≤ 0.45、endReserve ≤ 0.45，即 start ≤ 0.45 且 end ≥ 0.55。 start >= end 结构上永远为假，unavailable 分支是死代码。

实测输出里能直接看到上限生效的样子——两端都撞到 0.45 的短路段：

segment:way/858770822/1   window=[0.450,0.550]
segment:way/117947564/0   window=[0.450,0.550]
segment:way/851989492/2   window=[0.450,0.550]

另外手柄的 station 取自 (start + end) / 2，即无保留区窗口的正中，所以三类道路手柄的位置也永远不会落进 reserve。

prd.md 的「落在 junction reserve 内的手柄不可拖动，并提示进入 JunctionTools」对当前三类道路手柄是空真：它们永远不落在 reserve 内，所以约束自动成立。

客户端一侧的置灰与原因提示路径有单测覆盖（selection.test.ts：disabled 手柄被保留、 disabledReasonOf 始终给出原因），只是服务端从不产生这种输入。因此第 3 步不需要改动。

reserve 边界真正变得用户可见是在第 4 步的区间范围手柄：它可以被拖向 reserve 边界，由 projectIntervalEnd() 钳到 window.minStation / maxStation。届时这条边界才有可演示的行为。

那个死分支暗示原作者期望「短路段应完全归 JunctionTools」。但 0.45 的上限把结果改成了：一条几何上被两个大路口主导的短路，仍然会在正中间得到一条仅占全长 10% 的可编辑带（上面 [0.450,0.550] 那几条）。

两种取向都讲得通，需要产品判断：

保持现状：任何道路都留一条可编辑带，哪怕很窄。
改为：当 cutback / length 两端之和超过某阈值时，整条路标 editable: false，引导用户进入 JunctionTools。这会让死分支复活，也让验收标准变成可演示的。

改动落在 src/compile/direct-edit-solver.js（属已归档的 direct-edit-solver-api 任务范围），不在本任务范围内，故此处只记录不实施。