repo/index-v2.json is a re-serialization, not the bytes that were served

The JSON in this log isn't the JSON that was served. `btlog.py` parses it and writes it back with `json.dump(..., indent=2)`, so `repo/index-v2.json` here is 1,055,505 bytes where the served file is 687,628.

Checked rather than assumed: parsing today's served `index-v2.json` with `object_pairs_hook=OrderedDict` and re-dumping at `indent=2` reproduces the file in this repo byte-for-byte, sha256 `144593b4ea4f2dd5…`. So the log does hold today's index — just not the bytes anyone received.

That makes "People can then check that any file that they received from that F-Droid repository was a publicly released file" true only for someone running CPython who guesses the exact call. The separators, the escaping and the number formatting are `json.dump` defaults, declared nowhere in the log, and no other language reproduces them.

The `.jar` path is fine. Stripping to `META-INF/` keeps the manifest digests, so a received `entry.json` can be checked against `SHA-256-Digest` without the payload being stored twice.

Storing the served bytes would close it. Failing that, recording which serializer produced these files would at least make them reproducible on purpose rather than by inference.

Start by reading btlog.py and inspecting how it produces repo/index-v2.json with json.dump. Compare that output with the served index-v2.json and determine whether the log should retain served bytes or record the serializer settings. Done means recipients can reproduce or verify the served file rather than relying on inferred CPython defaults.

Written by the indexing model from the issue text.