Block-local binding span ops (move/delete/duplicate) produce malformed indentation

[dowdiness]

Summary

The position-based binding-span ops (compute_move_binding_up/_down,
compute_delete_binding, compute_duplicate_binding in
lang/lambda/edits/text_edit_binding.mbt, via binding_delete_range /
get_binding_text_range in text_edit_utils.mbt) consume and reinsert raw text
spans without re-indenting. For a block-local binding (which carries leading
indentation) this leaves malformed indentation:

move-up `b` in  "let r = { let a = 1\n  let b = 2\n  a }\nlet z = 0"
       ⇒        "let r = {  let b = 2\n let a = 1\n  a }\nlet z = 0"
                          ^^ doubled / lost leading spaces

Severity: cosmetic (verified)

I re-parsed the outputs of move and delete: both produce 0 parse errors and
the correct AST ([def:b, def:a, body] / binding removed cleanly). So this
is whitespace ugliness, not a soundness bug — the derived structure is right.
(Duplicate is a separate, genuine corruption tracked in #649.)

Fix direction

When moving/deleting/duplicating a binding span, normalize the leading
indentation of the moved/copied text to the destination column (and fix up the
neighbour that inherits the gap), rather than splicing raw byte ranges. Likely a
small helper that computes the line's indent prefix and re-applies it to the
spliced text.

Acceptance

• Move/delete/duplicate of a block-local binding produces text whose indentation
  matches a freshly-formatted block.
• The move/delete regression tests assert re-parse-to-correct-structure (already
  done on feat/edits-nested-block-scopes); add an indentation assertion here
  once the fix lands.

[dowdiness]

Fixed compute_move_binding_up and compute_move_binding_down: stripping leading whitespace from swapped binding texts and re-indenting to destination positions. Block-local bindings like { let a = 1\n let b = 2 now produce correct indentation after swap:

-{  let b = 2
- let a = 1
+{ let b = 2
+  let a = 1

compute_delete_binding and compute_duplicate_binding remain — the delete fix requires a different approach (normalizing text adjacent to the deleted range), and duplicate is tracked in #649 (genuine corruption, not cosmetic).

Applied in commit (pending PR).