fix(checker): give each voice preflight its own trace and span id

[abhijaisrivastava15]

The problem

fi_verify_voice.py sends its preflight span with a hardcoded trace id and span id, and fi_verify.py on the same docs site sends the identical pair:

# public/fi_verify.py:53   and   public/fi_verify_voice.py:80
span = {"traceId": "4bf92f3577b34da6a3ce929d0e0e4736", "spanId": "00f067aa0ba902b7", ...}

default.spans is a ReplacingMergeTree sorted on (project_id, observation_type, service_name, toStartOfHour(start_time), trace_id, id). Two spans that agree on that key are the same row, and the later one replaces the earlier.

So two preflights in one project in one hour collapse into a single row. Run the text cookbook and the voice cookbook against the same project, or run either checker twice, and only one probe survives. Step 1 of both pages tells the reader a call named futureagi.voice.preflight is now in their project's Voice tab, and that sentence can be false through no fault of theirs.

No gate catches it, because V1 reads the receipt preflight wrote to disk, not the row in the project.

How it surfaced

The trace-list capture on #844 showed a probe row reading futureagi.preflight in a project where only the voice checker had ever run. @khushalsonawat caught it in review. It was the text checker's probe, still holding the shared key from an earlier run in that hour.

What

Fresh ids per send, two lines.

span = {"traceId": os.urandom(16).hex(), "spanId": os.urandom(8).hex(), ...}

The printed sha256 in the page's install block moves with it, and the notebook's copy moves in future-agi/cookbooks#15.

How it was tested

Three consecutive send() calls captured against a local sink:

trace dfa334a148cc954ec9f1ec0b7aa3dc3e  span f02ec90f49583949
trace fc90b2fd20d71dda13eae22f294e1c47  span c50cf5210952bc6a
trace ad6d45dd15defb648e02c0ca9b62d3ff  span a0324a3611000095
distinct: 3 of 3

Span name, shape and attributes unchanged, so every gate reads exactly as before. preflight against an unreachable endpoint still fails closed.

Notes for reviewers

public/fi_verify.py still has the hardcoded pair. It is already published and its sha256 is printed on the text cookbook, so changing it is a separate PR with its own page edit. Worth doing: the collision needs only one of the two to move, but the text checker has the same "run it twice" problem on its own.

[khushalsonawat]

LGTM