docs: correct the Balanced/Aggressive pHash ceilings in the README table

The table said 12 and 18 bits; DuplicatePolicy says 15 and 22, and the device agrees: with a
22-photo library the fit has too little data and falls back to the ceiling, and the results screen
prints "similarity cut: pHash <= 15 bits (default)" - 15, not 12.

The RGB column of the same table already matched the enum (60 and 84), which is what a pHash-only
edit looks like: the ceilings were evidently retuned and this one column was not carried along.

The old 18 was not invented - it is the measured F1 optimum that AGGRESSIVE's doc comment calls out
("set above the measured F1 optimum (~18 on real photographs)"), i.e. the value the ceiling is
deliberately placed above rather than the ceiling itself. Saying so here keeps the corrected row
from reading as though a measured optimum had been changed.

README.md

@@ -121,8 +121,8 @@ Sensitivity presets (both values are ceilings; the pHash one is adapted per scan
 | Policy | pHash ceiling | RGB ceiling | Notes |
 |---|---|---|---|
 | Exact copies only | – | – | byte-identical files, no decoding at all |
-| Balanced (default) | 12 bits | 60 / 192 | the recommended setting |
+| Balanced (default) | 15 bits | 60 / 192 | the recommended setting |
-| Aggressive | 18 bits | 84 / 192 | catches heavier re-edits |
+| Aggressive | 22 bits | 84 / 192 | catches heavier re-edits |
 
 Banding gives *exact* candidate recall for pHash distances up to 7 (see the comment in
 `DuplicateGrouper`).