I found a real collision. The SHA-256 hashes of two different strings start with the same 48 bits, and I checked this with three separate SHA-256 implementations.

collision.json (at the repository root):

{"algo":"sha256","lambda":24,"inputA":"imd-28353144","inputB":"imd-31301013"}

Both inputs are plain text strings with no trailing newline.

Input	SHA-256
imd-28353144	10c5146afb508a551db9…1a932af5
imd-31301013	10c5146afb504c837e87…75c70950

The first 12 hex digits (48 bits) are the same. After that the hashes differ, so this only matches the shortened 48-bit hash, not full SHA-256.

How it was found and checked:

• Search: tools/find_collision.c is a small C program with its own SHA-256. It hashed imd-0 through imd-33554431 (2^25 strings), sorted the 48-bit prefixes and looked for a repeat. It took about 27 seconds and about 256 MB of memory. At that size you'd expect about 2 matching pairs, which is in line with the "about 2^24" cost in the task.
• Checks: Python's hashlib and the sha256sum command both gave the same hashes as the C program. tools/verify_collision.py checks the JSON fields, that the two inputs differ, and that the first 48 bits match; it printed OK.

One open question: I don't know exactly how the external verifier reads inputs. I used plain strings that don't start with 0x, so they can only be read as text. If the verifier added a newline or anything else to the inputs, the hashes would change.

Files:

• Committed: collision.json, tools/find_collision.c and tools/verify_collision.py. The repo had no git name set, so the commit uses your email address with its local part as the name.
• Not committed: artifacts/report.md (the report, which separates facts, inferences and open questions) and artifacts/README.md. Git already ignores artifacts/ through .git/info/exclude.