Support merging tags through the API

[sethfitz]

Support merging tags through the API

Tag merge has been available in the web UI since v1.43.0 (#1175), but the tags API only
supports list, retrieve, create, and delete. A scripted consolidation therefore has to
hand-roll it: PATCH every affected bookmark's tag_names one at a time, then delete the
tag that is left behind. That is not atomic, and it leaves an orphaned tag if the caller
stops halfway or forgets the cleanup — which the web UI's merge never does.

This exposes the existing merge as a detail action on the target tag, in the same spirit as
#1411 exposing tag delete.

POST /api/tags/<id>/merge/

{ "merge_tag_ids": [2, 3] }

Returns 204 No Content.

Design decisions

Detail action on the target, not POST /api/tags/merge/. The tags API addresses tags by
ID everywhere else, so the target belongs in the path like it does for retrieve and delete.
It also follows the convention the bookmarks API already sets for non-CRUD operations on a
single resource — POST /api/bookmarks/<id>/archive/ — rather than introducing a
collection-level pseudo-resource. The practical benefit is that the target goes through
get_object(), so a tag belonging to another user 404s through exactly the same mechanism
as retrieve and delete, with nothing new to get wrong.

Merge tags are named by ID. Mixing an ID in the path with names in the body would be
incoherent, and IDs avoid the question of what a name that does not resolve should mean.
TagMergeForm matches names case-insensitively because it is fed by the tag autocomplete;
an API client that has names already has the IDs from GET /api/tags/.

Unknown or foreign merge tag IDs are a 400, not a 404. The addressed resource — the
target tag — does exist; the payload is what is invalid, and the response names the offending
IDs. Merge tags are resolved through get_queryset(), so another user's tag is rejected as
non-existent rather than merged, and ownership has one enforcement point rather than two.

204 No Content, matching archive/unarchive and tag delete. Nothing about the target
tag's own representation changes. Returning a count of retagged bookmarks would be useful for
tooling — happy to add that if you would prefer it, but it seemed out of scope for parity with
the web UI.

Shared transaction

The transaction.atomic() block moves out of bookmarks/views/tags.py into
bookmarks.services.tags.merge_tags() unchanged — same queries, same order — so the view and
the API action cannot drift. The view keeps its success message and its existing tests, which
pass untouched.

Tests

Seven tests in bookmarks/tests/test_tags_api.py, covering the merge itself, the
exclude(tags=target_tag) branch where a bookmark already carries the target tag, a merge tag
that does not exist, the target listed among the merge tags, a missing/empty merge_tag_ids,
and both cross-user directions (foreign target 404s, foreign merge tag 400s and is left
untouched).