fix: validate sortBy/sortOrder before building ORDER BY clause

[aroh3006]

Fixes #468.

ListWithParams built the ORDER BY clause with
sortBy + " " + sortOrder, and both come straight from the
sort_by/sort_order query params on GET /api/v1/transcription/list
with no validation. Anything past the intended column name in sortBy
reaches the query text as-is.

sortBy is now checked against a fixed set of the actual sortable
column names (created_at, updated_at, title, status,
audio_path), and sortOrder against asc/desc. Anything else
falls back to the existing default sort (created_at desc) instead of
reaching the query, same as an empty sortBy already did before.

Tests. Added two tests in internal/repository/implementations_test.go
against an in-memory sqlite DB: a sortBy value with a trailing SQL
fragment is rejected and falls back to the default sort instead of
reaching the query, and a real column name still sorts correctly. Ran
the first one against the old code first, and the driver actually
received the injected text as part of the query
(ORDER BY id; DROP TABLE transcription_jobs; -- desc), confirming
the injection reaches the database layer. go vet and gofmt are
clean on the changed files, and the full internal/repository package
suite passes.

[clearlynotstefan]

Independent review: this issue is still present on current main (a353078f). GET /api/v1/transcription/list is auth-protected, but its sort_by / sort_order values still flow into ListWithParams, where the ORDER BY expression is built from caller-controlled strings.

This PR is still mergeable. Current main is only one commit ahead of the PR base, and that intervening commit changes README.md only, so there is no code-level conflict with this fix.

The Actions run is currently marked failed, but GitHub exposes zero jobs for that run, so there is no visible indication that the code or tests themselves failed. The patch is narrow, preserves the existing default sort behavior, and adds coverage for both rejected unknown sort fields and a valid sort field.

Given that the report has already been public for some time and the affected code remains in the released branch, merging or rebasing this fix promptly would reduce exposure rather than meaningfully increase it.