Validate a tar upload instead of storing it unread - #28947

Fixes #28913.

postFile checks the Content-Type header and, for zip, validates the archive with zip.NewReader before converting it. A tar is stored unread, so a gzipped tar sent as application/x-tar is accepted, hashed and returned as a valid file id. The failure then surfaces much later in whatever first reads the filesystem back, which in the report is preview, reported as "Unable to parse workspace tags" with a nil dereference underneath. As the reporter says, an empty template panics too, because the template content is never reached.

The upload path now walks the tar headers and rejects an archive it cannot read, so the mistake gets a 400 where it was made. Only headers are walked, so the cost is proportional to the number of entries rather than their contents. A gzip magic check gives that case its own message, since sending tar czf output is the easy way to hit this and the CLI accepts it.

This is the first of the three suggestions in the issue. I did not touch the reader on the preview side, and I did not add gzip support: accepting gzip changes what the endpoint means and is worth deciding separately, though the asymmetry with coder templates push is the part that cost the reporter the most time.

Tests: TestValidateTar covers a real tar, the all-zero block form that current uploads already use, a gzipped tar and non-archive bytes. TestPostFiles gains a GzippedTar case asserting a 400 whose detail mentions gzip, and an UnreadableTar case.

On what I ran: go test ./coderd/ -run TestValidateTar passes. I could not run the TestPostFiles cases locally, coderdtest.New does not come up in my sandbox and the run sat at files_test.go:46 until the timeout, so those two are unverified by me and rely on CI.