feat(#10706): add move contact hierarchy

[vikrantwiz02]

Description

Adds the move half of the Advanced Contact Management API: POST /api/v1/person/{id}/move and POST /api/v1/place/{id}/move, moving a contact and its whole subtree under a new parent.

This is the second consumer of the bulk-operations framework that landed with delete in #11236, and it needs no changes to that framework. The design was reviewed on the Move tab of the technical design doc and follows what we settled there.

How it works. The request validates the move, gathers the documents it touches, and queues a bulk operation, returning a job id immediately. Sentinel applies the changes in batches, and the caller polls GET /api/v1/bulk-operations/{id}.

Two actions are queued, named for the field each writes:

Action	Writes	Applied to
set-parent (new)	doc.parent	the source contact and every descendant
set-contact (existing)	doc.contact	the reports whose cached author lineage is stale, and any place whose primary contact moved

set-contact is reused unchanged because in both cases the value being refreshed lives in a property called contact: on a report it is the author reference, on a place it is the primary contact.

Every operation is self-contained, carrying the document id, the value it expects to find, and the new value to write, so the handlers compute nothing. An operation whose document changed since it was gathered fails rather than clobbering the newer edit, and every bulkDocs result is checked.

Validation. Ported from cht-conf's lineage-constraints: no cycles, only configured parent types, no move that strands a place's primary contact, the source's own primary contact must be a person, and a move to the parent the contact already has is rejected rather than writing identical values back. Violations return a 400 with the reason; anything else, such as a database failure during validation, propagates as a 500 rather than being reported as an invalid move.

Finding the reports. A move changes where the author sits, so the affected reports are the ones the moved contacts wrote, not the ones about them. These come from the nouveau reports_by_freetext index queried on exact_match:"contact:<lowercased id>". Results are paged with the bookmark rather than capped, so a prolific author is not silently truncated.

Scale. Ids are gathered first and documents are then read a page at a time and turned straight into operations, so only one page is held in memory at once. A district move can touch tens of thousands of documents and the request is the half of this that has to stay cheap.

Permission. A new can_move_contact_hierarchy, shipping assigned to no role. can_edit is held by almost every user and is a webapp permission, not appropriate for guarding a server operation that rewrites a subtree.

Endpoint shape. Per-type rather than a single /contact/{uuid} endpoint, following what delete shipped with, so a place cannot be moved through the person endpoint or the reverse.

One thing worth flagging for review: a move changes who can replicate the subtree. Moving a clinic between districts means the receiving district's offline users begin syncing those contacts and their reports, and the previous district's stop. That is what a move means, but it is an access change as much as a data change, which is part of why the permission is separate and admin-assigned.

The first commit lands the lineage manipulation helpers, which were written earlier but never merged while we focused on delete.

#10706

Code review checklist

• Readable: Concise, well named, follows the style guide
• Tested: Unit and/or e2e where appropriate
• Backwards compatible: Works with existing data and configuration or includes a migration. Any breaking changes documented in the release notes.
• AI disclosure: Please disclose use of AI per the guidelines.

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.