fix(tus): return 460 for checksum mismatches instead of 500

[Mortimer-RR]

Fixes #842

When FinishUpload rejected an upload because its checksum did not match, tusd reported a
generic 500, although the upload session was already deleted. Clients that retry a 500 kept
retrying an upload that no longer exists.

Changes

pkg/storage/pkg/decomposedfs/upload/upload.go FinishUpload:

• errtypes.ChecksumMismatch → ERR_CHECKSUM_MISMATCH, 460 (tus checksum extension);
• errtypes.BadRequest → ERR_BAD_REQUEST, 400.

The plain-PUT datatx paths keep their existing 419 for checksum mismatches.

Client impact: the desktop client classifies 460 as a normal (retried) error. The web
client already refused to retry 5xx, and tus-js-client doesn't retry 4xx other than
409/423, so for web uploads only the reported status changes.

Tests

• pkg/storage/pkg/decomposedfs/upload/upload_status_test.go: the mapping for a checksum
  mismatch, an invalid checksum format and an unsupported algorithm (fail on main).
• pkg/rhttp/datatx/manager/tus/tus_status_test.go: the real tusd handler over HTTP: a
  wrong checksum gets 460 (500 on main), a correct one 204.
• go test -race clean on both packages; pkg/storage/..., pkg/rhttp/...,
  internal/http/services/... pass.

🤖 Generated with Claude Code

[Mortimer-RR]

The test-integration failure (5 × "index out of range [0] with length 0" at
gateway_storageprovider_test.go:405, ListStorageSpaces returning no spaces right after
CreateHome) isn't related to this change: it reproduces on unmodified main (df725d0)
with the same Ginkgo seed:

  make build-ci && cd tests/integration && \
    go test -race -count=1 ./grpc/ -args -ginkgo.seed=1790950586

→ 95 passed, 5 failed on main, identical to this PR. The "gateway with a basic user
storage" specs pass on their own, so it's order-dependent: an earlier spec leaves state
behind. Could someone re-run the pipeline?