Map service errors to correct HTTP status codes (was 500)

Three more handlers had the same pattern as the RevokeShare bug fixed
in 0848488: the service returned a plain errors.New(...) for an
expected condition, so handleError fell through to its default 500
branch instead of mapping to 404/400.

  - browse.GetThumbnail → ErrNotFound (404 instead of 500) when the
    media row has no thumbnail path.
  - tag.RemoveTag → ErrNotFound (404 instead of 500) when the tag name
    does not exist. DELETE /media/{id}/tags/{unknown} now returns 404.
  - write.RegenerateSetCover → new sentinel ErrEmptySetForCover, mapped
    to 400 in handleError, when the target set contains no media files
    eligible to be promoted to a cover.

S15 (auth-boundary negatives) is tightened: the share-revoke step used
to accept {404, 500} as a workaround for the bug; it now requires 404.
A new section C2 locks in the three regressions above so they cannot
silently return 500 again.

Verified end-to-end via curl: DELETE /media/{id}/tags/unknown → 404,
DELETE /shares/unknown-token → 404. Full LLM e2e suite 15/15 still
passes against the rebuilt server.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

0 files changed, 0 insertions, 0 deletions