docs: render drill screenshots at a uniform width (BCTL-0)

[vineethkrishnan]

Summary

Fixes inconsistent screenshot text size in the storage backend drill doc. The images ranged from 1173px to 4206px wide, a 3.6x spread, because freeze sizes each image to its longest line. VitePress fits every image to the content column, so on-page text size is inversely proportional to pixel width: 01-config-validate (1173px, 27 characters) rendered with oversized text while 04-run-backup (4206px, 118 characters) rendered tiny.

All ten are now 4273px wide, so they scale to the same apparent font size.

Changes

Area	Description
render.sh	New. Renders every capture with identical settings and pins the width by padding the first line to a fixed column budget. Prints resulting dimensions so a width regression is visible
*.png	All ten re-rendered at 4273px. No capture content changed
README.md	Documents the uniform-width requirement and points at the script instead of the hand-run freeze command that caused the drift

Notes for review

Column budget is 120, not 80. My first attempt wrapped at 80, which split the status and snapshots table rows mid-timestamp. The real content maxes at 118 characters, so 120 is the smallest budget that keeps every capture unwrapped. Raising it later means re-rendering the whole set, which is why the script takes it as one variable.

freeze's --width flag does not solve this. It widens the canvas without scaling the font, so the text shrinks rather than staying consistent. Width has to come from the content, hence the padding approach.

An earlier measurement was misleading. awk length counts bytes, so the box-drawing separator in 06-status read as 240 "characters" when it is 80 box-drawing glyphs at 3 bytes each. True widths are 27 to 118.

Testing

• npm run docs:build passes
• All ten PNGs report a single distinct width (4273px)
• Heights match the pre-fix originals, confirming no capture wrapped
• Visually verified the narrowest (01) and a table-heavy one (06) render at matching glyph size