Tiles: take a blob's mimeType from what uploadBlob returns #11

The tiles appendix recommends `application/octet-stream` as the `mimeType` of every blob reference. On some PDS implementations that recommendation makes a tile unpublishable as soon as it contains a file whose type can be recognised from its bytes. The reference implementation (bluesky-social/atproto, packages/pds, actor-`store/blob/transactor.ts`) does two things that together cause it: - On `com.atproto.repo.uploadBlob` it sniffs the bytes and stores the blob under the type it recognises (`image/png`, `audio/wav`, `font/woff2`, ...). The type the upload declared is used only when nothing is recognised, which is the case for HTML, CSS, JavaScript and JSON. - When a record that references a newly uploaded blob is written, it compares the reference's `mimeType` with the stored type and refuses the whole write if they differ: "Referenced Mimetype does not match stored blob. Expected: image/png". So a publisher that follows the appendix and writes `application/octet-stream` everywhere succeeds for a tile made only of text, and fails at the `com.atproto.repo.putRecord` of the tile's record for any tile with an image, a sound or a font in it. appmosphe.re's publish page does exactly this and fails that way, for example with "Expected: audio/wav" for a tile carrying a WAV sample. `atile publish` does not fail, because it sniffs each file itself with the same file-type library and writes what it finds; that only works as long as its sniffing agrees with that of the implementation it publishes to. `uploadBlob` already answers with the complete blob reference, `mimeType` included. Using that reference as the resource's src is correct on every implementation: one that sniffs reports the type it stored, and one that does not reports the declared `application/octet-stream`, which is what the appendix recommended before. The content-type the tile is served with stays separate and unaffected.