docs: correct the VRAM batch-size guidance + make batch_size explicit

[Jammy2211]

Follow-up for PyAutoLabs/PyAutoFit#1452, found while diagnosing it. Two related changes.

1. The VRAM guidance was wrong

The __VRAM Use__ section of scripts/interferometer/modeling.py told users:

VRAM does not scale with batch size for the persistent buffers, so if the analysis fits within VRAM for batch_size=1 you should be able to push the batch size up (e.g. to 50) to maximise GPU throughput without running out of memory.

That is the advice that produces the failure it should prevent, at almost exactly the batch size it recommends. Memory splits into a fixed part and a per-evaluation part, and which dominates is the whole question. For interferometer data under a gradient search the per-evaluation part dominates, because the batched value_and_grad carries the whole forward tape.

The measured case: a 48-start SDP.81 fit needed ~1.79 GB per start — ~86 GB in total — and OOMed two nightly release runs, while a single start fitted comfortably.

Replaced with the fixed-vs-per-start split, the measured number, a pointer to start_here.py's batch_size=4, and a note that print_vram_use profiles the likelihood only unless passed gradient=True. Nautilus — the search this script uses — takes no gradients, so the default remains right here; the caveat is there so a reader doesn't carry the number to a gradient search.

2. Three sites left batch_size implicit

PyAutoLabs/PyAutoHands#228 added a static check for MultiStart* searches built without an explicit batch_size. It found three here:

• scripts/guides/modeling/searches.py:165
• scripts/imaging/start_here.py:313
• scripts/multi_galaxy/start_here.py:375

Behaviour is unchanged — None is already the default. What changes is that the choice is written down where a reviewer sees it. No bounded value was invented: these are CCD imaging, group and guide likelihoods, and picking a real number needs a measurement this change could not make. imaging/start_here.py is the one most worth profiling later — a user-facing entry point at n_starts=48, met first by someone on a laptop GPU.

Merge ordering

• After feat: warn before an unbatched MultiStartProdigy jvp exhausts memory PyAutoFit#1453 (merged ✅) — the prose mentions print_vram_use(..., gradient=True), which exists only there.
• Before ci: gate workspaces on the unbatched multi-start search check PyAutoHands#229, which turns the check into a required job.

Files

Four scripts (one is prose-only, three one line each); matching notebooks regenerated byte-preservingly and each re-verified as valid JSON. workspace_index.json gained the one cross-ref the navigator catalogue check asked for. scripts/check_sizes.sh passes; the checker reports the tree clean.

Could not update

Nothing. I checked whether autogalaxy_workspace carried the same false VRAM claim — it does not; its passage is vaguer but not wrong, so it is deliberately untouched. Its own four implicit-batch_size sites are PyAutoLabs/autogalaxy_workspace#205.