Let merge-permission users write through dolt_conflicts_<t>

[tbantle22]

Summary

Stacks on top of #11030. Adds a branch-control carve-out so a user with only Permissions_Merge on a branch can resolve a merge that produced data conflicts by writing through dolt_conflicts_<t> and via DOLT_CONFLICTS_RESOLVE. Lets a PR reviewer on the SQL workbench finish a conflicting merge without being granted full write access on the target branch.

Admission rule applied at every entry point — Write, OR (Merge AND MergeActive AND data conflicts exist):

• ProllyConflictsTable.Updater (dtables/conflicts_tables_prolly.go) — new gate via checkConflictsTableWriteAccess.
• ProllyConflictsTable.Deleter (same file) — replaces the bare Write gate from Gate DELETE on dolt_conflicts_<t> with branch_control Write permission #11030 with the same helper.
• DoDoltConflictsResolve (dprocedures/dolt_conflicts_resolve.go) — new dsess.CheckAccessOrMergeActive helper; "data conflicts exist" scoped to the working root.

The Updater path's source-table srcUpdater is constructed eagerly inside newProllyConflictOurTableUpdater, so a merge-permission caller admitted at the outer gate would otherwise be rejected by the inner WritableDoltTable.Updater Write check. To bridge that delegation chain:

• New dsess.ConflictsBypassMarker keyed on (db, branch, table). prollyConflictOurTableUpdater sets it on a derived context just for the source-table writer factory call.
• WritableDoltTable.Updater honors the marker as a Write-check bypass only when it matches the target table. A marker for t1 cannot leak into a write on t2.

Test plan

• Extended "Merge permission allows merge with conflicts" (branch_control_test.go) with the full positive workflow: merge-only user runs UPDATE dolt_conflicts_test (write goes through to source table), CALL DOLT_CONFLICTS_RESOLVE, CALL DOLT_COMMIT. Source-table direct writes remain rejected.
• New "Merge permission allows DELETE from dolt_conflicts_<t> to resolve conflicts" — exercises the DELETE path end-to-end.
• New "Merge permission does not allow conflicts writes outside an active merge" — without an active merge, even a merge-permission user is rejected by DOLT_CONFLICTS_RESOLVE and by direct source-table writes.
• go test ./libraries/doltcore/sqle/enginetest/ -run "TestBranchControl" passes.
• go vet ./libraries/doltcore/sqle/... clean.

Known limitation

When a merge-only user runs UPDATE/DELETE on dolt_conflicts_<t> with zero matching rows (e.g., empty conflicts table outside an active merge), the engine never invokes the writer's per-row methods, so the static error from the factory's permission check never surfaces. This is the same property that affects every WritableDoltTable write check — consistent with existing Dolt behavior. The negative test asserts via DOLT_CONFLICTS_RESOLVE and a direct source-table write instead, both of which run the gate regardless of matching-row count.

🤖 Generated with Claude Code

[reltuk]

LGTM!