Repair double-encoded box-drawing characters in two K1 2025 menus

[arlophoenix]

Four lines in the K1 2025 built-in camera and chassis light menus render as в”‚ instead of │, breaking the box borders. The bytes are U+2502 encoded as UTF-8, read back as CP1251, then encoded again — d0 b2 e2 80 9d e2 80 9a sits where e2 94 82 belongs. These are the only four occurrences in the repo.

Repairing the encoding exposed a smaller problem underneath it. The corrupt sequence is five bytes wider than the character it stood in for, and the padding on three of the four lines had been hand-fitted to the mangled render rather than to │, so correcting the bytes alone left those lines one to two columns short. The second commit pads them back to 65 columns, the width of every other menu body line in the repo. Nothing else in either file is touched.

Test plan

• grep -rn "в”" scripts/ files/ returns nothing
• All four lines hexdump as e2 94 82; no d0 b2 sequence remains anywhere
• bash -n clean on both files
• All 30 box body lines across the two files measure 65 columns, matching the repo-wide convention
• Both menus rendered locally with colour variables stubbed; right borders sit in the same column as the untouched USB Camera box
• Manual test pass (see checklist below)

Manual test pass

• Open the Built-in Camera Fix menu on a K1 2025 and confirm both description lines' right border sits in the same column as the rows above and below
• Open the Add chassis light control menu on a K1 2025 and confirm the same

Not addressed

Menu body lines are 65 columns while the frame drawn by top_line/hr is 67, so body rows sit two columns narrow. That is uniform across all 117 body lines repo-wide, including boxes this PR does not touch, and correcting it is a separate change.