Partly synced attachments are served as 500, truncated 200 or 404 with no way to tell them apart #81

Part of #80.

When an attachment has only partly synced to the cloud, the blob server still answers 200 and then the body stops at the first missing block, or the socket is reset before headers if the second block is missing. The cloud's attachments route turns that into a 500 with fetch failed, and a gap in the drive's index core turns into a core-shaped 500 (UNKNOWN_ERROR) because hypercore's "block not available" error is wrapped as a 500 and overrides the 404 the route had set. The client cannot tell "missing", "broken" and "not here yet" apart, and nothing on the server notices.

Fixes:

• fix(blob-server): return 404 for partially downloaded blobs comapeo-core#1350 makes core check the whole block range and return a coded 404 before sending anything.
• fix(attachments): return 502 when the blob server resets the connection #76 catches the reset on the cloud side and returns a coded 502. This stands on its own until the cloud is on a core with the 404 change.
• feat(attachments): add an attachment audit endpoint #88 adds an audit endpoint that lists the attachments the server cannot serve, with the device that has to sync again. feat(attachments): report attachments that could not be served to Sentry #89 reports every attachment the route could not serve to Sentry, and feat(attachments): audit attachments after each sync and report missing ones to Sentry #90 runs the audit after each sync, so missing media is detected on the server rather than by partners.