filesystemlog.json records no content digest, so 377 logged files -- including 57 signatures and 3 served APKs -- have no hash anywhere in the log

`repo/filesystemlog.json` records six fields per file: size, two timestamps,
mode, uid and gid. No digest. Where the index also covers a file that is
harmless, because `index-v2.json` carries `sha256` and the index is in the log.
Where the index does not cover it, there is no hash in the log at all.

Counted over today's HEAD (`bc470e9`): 942 entries in `repo/filesystemlog.json`,
565 of which appear with a `sha256` in `repo/index-v2.json`, and **377 of which
do not**. The 377 are 281 `.png`, 57 `.asc`, 19 `.json`, 11 `.sig`, 3 `.jar`,
2 web files, and three APKs -- `Checkey-0.1.2.apk`, `LocationPrivacy-0.2.apk`
and `LocationPrivacy-0.3.apk`. All three are still served; a range request to
each returns 206.

Worked instance, so this is not an inference: I downloaded
`https://guardianproject.info/fdroid/repo/Checkey-0.1.2.apk`. It is 842,881
bytes, matching the size in `filesystemlog.json` exactly, and its sha256 is
`754701dbac52de5ca3930c2393970c03ef9aa07d1456911e9bf254d6014e0645`. That string
does not appear anywhere in HEAD. So for that file the README's "check that any
file that they received ... was a publicly released file" holds up to filename
and byte count, and any 842,881-byte file named `Checkey-0.1.2.apk` passes every
check this log supports.

The `.asc` files are the ones I would fix first: they are the detached OpenPGP
signatures over the APKs, the artifact a user checks *with*. A digest field in
`filesystemlog.json` closes all 377 without changing the shape of the format.

Much smaller, same file tree: `repo/index.jar.HTTP-headers.json`,
`repo/index.xml.HTTP-headers.json` and `archive/index.jar.HTTP-headers.json`
last changed 2017-04-06 and still carry `"Date": "Thu, 06 Apr 2017 21:33:18
GMT"`. Alongside an `index-v2.json` that updates daily they read as current
evidence of what the server served, and they are nine years old.

*Drafted with AI assistance.*

Start with repo/filesystemlog.json and compare its entries with the sha256 records in repo/index-v2.json; inspect how the log and the three HTTP-header JSON files are produced. Done means the logged artifacts have digest coverage, especially the listed signatures and APKs, and the stale header metadata is addressed without breaking the existing log format.

Written by the indexing model from the issue text.