Fix content_type detection for extensions GitHub rejects (#32)

[drogers0]

Fixes #32.

Problem

detectContentType relied on mime.TypeByExtension, whose output GitHub's upload policy endpoint (POST /upload/policies/assets) rejects with 422 content_type is not included in the list for many extensions:

• .jpg (the reported bug): on Windows, Go's mime reads the registry, which commonly returns legacy image/pjpeg / image/jpg. GitHub only accepts image/jpeg. Renaming to .jpeg worked because that path yielded image/jpeg.
• Broken on macOS/Linux too: for several code/data extensions (.md, .yaml, .yml, .jsonc, .cs, .php, .py, .patch, .cpuprofile, .ipynb, .tsx, .tgz) Go's mime table returns nothing, so detectContentType fell back to application/octet-stream, which GitHub rejects for text types. Uploading these advertised file types failed on every platform.
• Wrong values: .wav→audio/x-wav, .cpp→text/x-c, .ts→video/mp2t (the well-known MPEG-TS collision), .pdb→application/vnd.palm, .sql→application/x-sql — all rejected.

Fix

Expand the existing githubContentType override map (which previously held only .log) with 21 entries. Each accepted value was verified against GitHub's live policy endpoint (HTTP 201), and the type Go would otherwise send was verified rejected (422). Only extensions Go gets wrong are pinned; extensions whose mime value GitHub already accepts continue to use the mime.TypeByExtension fallback.

Notable verified mappings: .ts→text/typescript, .tsx→text/tsx, .js→text/javascript (GitHub rejects application/javascript), .yaml/.yml→application/x-yaml (GitHub rejects text/yaml).

Testing

• Added cases to TestDetectContentType in internal/upload/upload_test.go.
• go build ./..., go vet ./..., and go test ./... all pass.