Probe what a BK4819 read presents, and say plainly that it is not the guard yet

UVK5_BK4819_PROBE reassembles the sixteen bits a read clocks out and logs them against the register's own value: 1566 of 1566 agree on the working model. That agreement is not proof -- removing the skip_falling fix, which is exactly the historical left-shift regression, leaves the reassembled word unchanged, so this observation point is not the one the guest samples at. tools/test_bk4819_readback.sh therefore stays the guard.

tools/test_bk4819_readback.py is the working draft of a portable replacement (no source patch, no rebuild, no ARM gdb) and is deliberately NOT registered in run_tests.sh, so a proven guard is not swapped for an unproven one. Both the file and the two READMEs say so.

README.md

@@ -401,6 +401,15 @@ slot and resets. Both halves are reachable from the page.
 - `tools/uvk5_slots.py` does the same offline: write a slot into a flash image, and print
   what each slot holds.
 
+### The readback guard, and a draft that is not one yet
+
+`tools/test_bk4819_readback.sh` guards the reading-shift bug -- a register read delivering its
+value one bit off. It needs an ARM gdb, so it only runs where one is installed.
+`tools/test_bk4819_readback.py` is the portable replacement in progress, and **it is not the
+guard yet**: it passes on the working model, but removing the fix does not make it fail, so it
+does not observe what the guest actually samples. It is deliberately not registered in
+`tools/run_tests.sh`, so that a proven guard is not replaced by an unproven one. The
+observation point has to move to the driver's sampling edge before it takes over.
 ### Which build renders correctly, and how that is decided
 
 The page draws the display controller's **own memory**, not the firmware's framebuffer, so it