Found: 2026-08-31, reviewing palace_multi_restored_multi.jpg (samples3_v2_multi) against the uploaded original. Status:
Visual inspection of the restored image shows two distinct defects that the reported quality metrics (1.09–2.54 bytes mean Δ per region) did not surface:
1. across roughly x: 2820–3400, y: 850–1250 — isolated blocks with visibly wrong colour (blue/white/tan/dark-green speckling), not smooth ~1-byte noise.
2. at x: 2980–3520, y ≈ 1500 — a contiguous row, not random scatter.
Against the recorded palace_multi region list (v2-multi-region-implementation):
• Region 3: (3000, 900, 700×600) → bounds x 3000–3700, y 900–1500. The scattered-dot area (x 2820–3400, y 850–1250) falls inside this region.
• Region 5: (2800, 1500, 700×500) → bounds x 2800–3500, y 1500–2000. The line artifact sits exactly on y=1500 — the where region 3 ends and region 5 begins.
The line sitting precisely on a shared region boundary is very unlikely to be coincidence.
Mean Δ per region is averaged across thousands of blocks (region 3 ≈ 6,688 blocks). A single bad row (≈ 87 blocks) or a handful of scattered bad blocks barely moves an average of that size. This is the same blind spot the project's own session lessons flagged for XOR float precision ("mean Δ... visualscan would have missed it") — recurring here one layer up, at the region-boundary level instead of the pixel/coefficient level.
Off-by-one or inclusive/exclusive mismatch in block-row assignment at a shared region boundary — e.g. the topmost row of 8×8 blocks in region 5 (or the bottom row of region 3) being assigned to the wrong region's permutation/index during restoration, or the two regions' block-row ranges overlapping by one row instead of abutting cleanly.
1. Compute a (not just mean) for region 3 and region 5 — expect a spike of severely-wrong blocks rather than the smooth ~1.2-byte distribution seen elsewhere.
2. Check block-row boundary math specifically where two regions share a y-coordinate (900 and 1500 are both clean shared edges here) — verify <= vs < is applied consistently between the encrypt pass and the restore pass.
3. Re-run the scattered-dot check on region 3 alone (in isolation, single-region) to see whether the isolated bad blocks persist without the adjacent region present — would rule in/out a multi-region interaction vs a region-3-specific bug.
4. Repeat for detail_multi and subject_multi samples — check whether their region boundaries (also documented in v2-multi-region-implementation) show the same line-at-boundary pattern, which would confirm this is systematic rather than palace-specific.
Source image: user-uploaded photo matching https://webdav.critchley.biz/BuckinghamPalace/samples3_v2_multi/palace_multi_restored_multi.jpg (not independently re-fetched — 401 auth error from this session; correlation done against the uploaded copy and the coordinates on record).