fix(gui): stop the settings scroller leaving its content, and fill the table when columns are hidden

[donislawdev]

Two reported interface faults, and three things found while fixing them.

Reported

The Settings window scrolled off the top of itself. Dragging its scrollbar upwards pushed
everything down and left a blank band above the first setting.

Cause, measured on real Tk: viewport 855 px, content 452 px, region 0 0 807 452. Tk holds a view
inside its region only while the region is TALLER than the window - with a shorter region the canvas
moves its origin above the content, and yview keeps reporting (0.0, 1.0) while it does. One
scroll-up left canvasy(0) at -360. After: the region reads 0 0 807 855 and the same scroll
leaves it at 0.0.

The wheel never showed this because ScrollableFrame.scroll() guards on can_scroll(), while the
scrollbar is wired straight to canvas.yview and never passed through that guard. Clamping the
region instead of duplicating the guard covers the wheel, the scrollbar and any future caller at
once.

Hiding columns left the Connections table half empty. The table refuses ttk stretch
deliberately - ttk recomputes a stretch column on the next <Configure> and a dragged width visibly
snaps back - and the cost of that decision only shows once columns can be hidden. Measured in a
1076 px tree: 17 columns sum to 1611 px, so the horizontal scrollbar has work and that is correct,
but 2 columns sum to 205 px and leave 871 px of bare background.

fitted_widths() carries four rules, each with its reason: only ever WIDEN, so a width the user
dragged to is never taken back; share the slack in proportion to natural width, so a column born
wide stays the wide one; cap each column at three times its natural width, the same ceiling a drag
gets; and when the caps bind, leave the remainder rather than break one. The memo (_fitted_for) is
a rule too, not an optimisation - a fit is asked for when the visible set changes or the widget is
resized, and a column drag changes neither, so the chosen width stands.

Measured after: 4 columns, the reported case, take the full width; 2 columns leave 461 px and 1
leaves 674 px, every column standing on its cap.

Found on the way

An assertion that could not fail, inside the guard that guards the guards.
test_the_repository_scanners_stay_out_of_what_is_not_in_the_repository asserted that a maintainer
brief is not scanned - by naming a file deleted in August. The scanner could never have returned it
whatever the skip list held, so emptying that list changed nothing and the guard still read as
proof. Only the mutation runner said otherwise. The test now plants a brief for the length of the
scan, so the skip has something to skip, and the mutation is caught.

The language files were not sorted, and nothing checked. One pair was out of order in both files
identically, and the same pair is out of order in the merge base, so it predates this work. Swapped
at byte level, because rewriting a text file on Windows turns LF into CRLF and the repository is LF.
The new guard was shown able to fail before being believed.

The row limit said the same thing twice - 50000 rows (0 = off) 0 = no limit. Checked rather
than assumed: the two other fields with an "(0=off)" unit have no hint to carry it, so row_limit
was the only one with both. The unit is now bare.

Verification

• Full suite 1134 passed, plus the GUI smoke script.
• Every mutation in the registry caught: 102, survived 0, with the deliberately unparsable canary
  reporting BROKEN as it must. The registry had one survivor before this branch.
• Both fixed surfaces captured live from real Tk with PrintWindow, not reasoned about: the settings
  window sits flush at the top after a scroll-up, and the four columns span the table.
• No regression on the Control page, whose content IS taller than its viewport: its region stays at
  the content height, scrolling down works and scrolling up clamps at 0.

Said out loud rather than left to be discovered

• "Slack 0" is measured against winfo_width(), and a Treeview's usable width is 4 px less -
  2 px of border a side, constant, checked at two different widths. So xview reads 0.9963 and the
  horizontal scrollbar stays technically active over those 4 px. Not corrected by subtracting 4: that
  constant belongs to the theme and the platform and cannot be checked on the Linux runner, which is
  exactly the class of thing a Windows-only check waves through. There is no visible difference.
• With one or two narrow columns shown, the cap leaves real space over. That is the agreed behaviour,
  not an oversight - lifting it would mean a fit reaching a width no drag could.
• A suspicion the measurement killed, recorded so nobody re-opens it: a neighbouring loop looked like
  the same vacuous-assertion fault, comparing path prefixes with a backslash against paths normalised
  to forward slashes. It is not - the source uses forward slashes, and patching the skip list by hand
  reddens that loop correctly with 65 leaked files. Nothing was changed there.
• Duplicate-looking rows with columns hidden are by design and were left alone: the columns that tell
  those rows apart are the hidden ones.