Rename and/or toggle merge and/or update write-semantics (incl. the full_delivery batch fields) and/or the parse profile on a FileFolder.

Ordering: deterministic pre-checks FIRST, then write-semantics, then rename, then merge_enabled, then the parse profile LAST — a request that enables merge and sets a profile together must see the merge state this same request just wrote. Each block commits its own transaction internally (full cross-block atomicity is out of scope — see the "Atomicity contract" comment below), so every failure mode that's deterministic from the request body + the folder's state at the start of the request (not a race) is checked upfront, before any block runs: a request like {merge_enabled: true, write_semantics: "replace_overlap", coverage_columns: ["bad_col"]} on a folder with existing subfolders fails on the pre-check with no side effect at all, instead of committing the semantics change and then 409-ing on merge_enabled. Similarly a rename that collides with a sibling name is caught before the semantics block runs, not after. The parse-profile pre-check mirrors this: a profile on a folder that is not merge-enabled and is not becoming one in this same request is rejected upfront (400), before any block runs. Note the collection-schema subset check inside the semantics block still uses the CURRENT merge_database_id, which is None when merge_enabled is being turned on in this same request (the check is then skipped since there's no collection schema yet); a bad coverage column in that combination surfaces later as a per-file merge_error on the next merge rather than a 400 here.