Stop a locked canvas layer from being reordered or displaced [#1248]

[claytonlin1110]

Summary

• prototype/canvas-layer-controls.html's summary copy promises "Lock brand elements so they cannot move by accident," but locking a layer only disabled its Remove button. The Up/Down buttons only disabled at the very top/bottom of the stack, with no check for locked at all.
• This means: (a) a locked layer could still be moved directly via its own Up/Down buttons, and (b) an unlocked neighbour's Up/Down could displace a locked layer by swapping positions with it — a single step only ever swaps with the adjacent layer, so the locked layer's position was never actually protected.
• Extracted canMoveLayer(list, index, delta) / reorderLayers(list, index, delta) as pure, exported functions: a move is allowed only when neither the layer being moved nor its target neighbour is locked. Both the button disabled state and the actual move() now go through the same check, and reorderLayers never mutates its input.

Why this is useful

Closes issue #1248 (filed against this exact gap: "Locking a canvas layer doesn't stop it being reordered or displaced, despite the lock's stated purpose"). Small, self-contained, single-file fix with a pure, directly-testable function pair — not navigation/routing, and not the active bl:active-step issue (#1326), so it's submitted independently of that scope per current repo direction.

Verification

• npm test — 104/104 smoke test files pass
• Extended prototype/canvas-layer-controls.test.js:
  • the locked layer itself cannot move
  • an unlocked neighbour cannot displace it by moving toward it
  • two unlocked layers can still freely swap
  • reorderLayers returns a new array on an allowed move and the same reference (no-op) on a refused one, without mutating the input

Conflict avoidance

• Single-file logic change to prototype/canvas-layer-controls.html (two new pure functions + three call sites) plus an extension of its existing test file. No nav, shell, or other screen files touched.