fix(upload): compare media type only when enforcing pinned Content-Type

[acoshift]

What

The signed direct-upload handler (PUT /uploads/{token}) enforced the grant's pinned Content-Type with an exact string match:

if g.ContentType != "" && r.Header.Get("Content-Type") != g.ContentType {
    jsonFail(w, "content type mismatch", http.StatusOK)
    return
}

So a client that adds a standard parameter — e.g. application/pdf; charset=utf-8 against a grant for application/pdf — was wrongly rejected, even though it's the same media type.

Fix: compare only the media type (type/subtype) via mime.ParseMediaType on both sides, per RFC 7231 §3.1.1.1.

Why it's safe (not a constraint bypass)

• The body is streamed to storage without sniffing, so the pin was always a declared-media-type check, never a content guarantee. Ignoring parameters that don't change the media type preserves exactly that constraint.
• A real mismatch is still rejected: text/plain vs application/pdf → got != want → fail (existing TestUploadDirect_ContentTypeMismatch still passes).
• Fail-closed: a malformed/empty client Content-Type parses to "" and is rejected when the grant pins a type.
• ParseMediaType lowercases, so the comparison is correctly case-insensitive (media types are case-insensitive per RFC) — not a regression.
• Still gated by g.ContentType != "" (unpinned grants accept anything, unchanged).

Tests

TestUploadDirect_ContentTypeAllowsParams: grant application/pdf, PUT application/pdf; charset=utf-8 → 200 ok. Genuine regression guard (fails on the old exact-match). The existing mismatch test is retained.

Verification

• go build ./... ok; gofmt/go vet clean.
• go test -run TestUploadDirect_ContentType . — 2 pass (mismatch + new allows-params); dropbox tests run on the in-memory bucket.