acc: cover config-remote-sync write-back for split lists

[ilyakuz-db]

Stack

	PR	What it does
1	this PR	Acceptance coverage for split-list write-back; goldens record the pre-fix corruption
2	#6117	Route each change to the one block that defines it
3	#6135	Removing an element defined in several blocks deletes it from each
4	#6134	A key change is written as a key rewrite in every defining block

Review in order — each PR is based on the one above it.

Changes

Adds end-to-end coverage for bundle config-remote-sync write-back when a resource's list field is defined in more than one physical YAML region — a top-level resources.<type>.<name>.<list> block plus a targets.<target> override, possibly spread across included files.

Six directories under acceptance/bundle/config-remote-sync/split/ sharing one test.toml: keyed_edit, keyed_twoblock, keyed_remove, multifile, positional, isolation. Unlike the existing directories here they omit Cloud = true, so they run against the in-process test server under both deployment engines and therefore execute in normal CI.

The committed goldens record today's behaviour, which is wrong. That is deliberate: the fixes land on top of this and each shows up as a golden diff — corruption on one side, correct output on the other. What the goldens currently show:

• keyed_edit — editing a task defined only in the target block appends a keyless - timeout_seconds: 111 element to the top-level block; the next sync then reports tasks[task_key='']: remove for the element it just created.
• keyed_twoblock — a field set in both blocks is written to the top-level copy, but the target's value is the deployed one, so the edit silently has no effect.
• keyed_remove — removing one task per block fails with remove index key out of bounds (idx 2, len 2), because a merged index is used against a block with fewer elements. Removing a task defined in both blocks deletes only the top-level half, orphaning the other.
• multifile — an edit to a task defined in an included override file is written to the top-level databricks.yml instead.
• positional — a field edit on a target-block pipeline cluster fails with parent path ... does not exist.
• isolation — a rename of a two-block task is applied by guessing, leaving the task duplicated.

Each script states the scenario it covers next to the step that exercises it.

Why

Loading merges the separate YAML regions into one list (keyed lists are also sorted by key), but on disk they stay separate regions that have to be edited independently. A remote change is expressed against the merged view, so write-back has to map it back to the right (file, block, position).

config-remote-sync runs unattended — nobody reads its output or exit code — so a silently wrong write is the worst outcome. None of this was covered before: the existing directories are all Cloud = true, so they don't run in normal CI, which makes "fails before the fix, passes after" impossible to demonstrate. validation_errors showed the hermetic path works, and these follow it.

The single-block path is already covered by job_multiple_tasks, which exercises edit, add, remove and rename on a resource defined in one block. It stays byte-for-byte unchanged through the whole stack, which is the regression evidence.

Tests

This PR is only tests. Both engines pass locally, in seconds, with no cloud access.

[github-actions]

Waiting for approval

Could not determine reviewers from git history.
Round-robin suggestion: @lennartkats-db

Eligible reviewers: @andrewnester, @anton-107, @denik, @janniklasrose, @lennartkats-db, @pietern, @shreyas-goenka

_{Suggestions based on git history. See OWNERS for ownership rules.}

[eng-dev-ecosystem-bot]

Integration test report

Commit: 269d3f2

Run: 30752913462

	Env	💚​RECOVERED	🙈​SKIP	✅​pass	🙈​skip	Time
💚​	aws linux	4	4	313	1073	4:12
💚​	aws windows	4	4	315	1071	5:53
💚​	azure linux	4	4	313	1072	4:15
💚​	azure windows	4	4	315	1070	6:47
💚​	gcp linux	1	5	313	1073	4:05
💚​	gcp windows	1	5	315	1071	6:02

8 interesting tests: 4 RECOVERED, 4 SKIP

	Test Name	aws linux	aws windows	azure linux	azure windows	gcp linux	gcp windows
💚​	TestAccept	💚​R	💚​R	💚​R	💚​R	💚​R	💚​R
🙈​	TestAccept/bundle/invariant/no_drift	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S
🙈​	TestAccept/bundle/resources/vector_search_endpoints/drift/recreated_same_name	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S
🙈​	TestAccept/bundle/resources/vector_search_indexes/recreate/embedding_dimension	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S
🙈​	TestAccept/ssh/connection	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S
💚​	TestFetchRepositoryInfoAPI_FromRepo	💚​R	💚​R	💚​R	💚​R	🙈​S	🙈​S
💚​	TestFetchRepositoryInfoAPI_FromRepo/root	💚​R	💚​R	💚​R	💚​R
💚​	TestFetchRepositoryInfoAPI_FromRepo/subdir	💚​R	💚​R	💚​R	💚​R

Top 3 slowest tests (at least 2 minutes):

duration	env	testname
5:43	azure windows	TestAccept
4:58	gcp windows	TestAccept
4:48	aws windows	TestAccept

[ilyakuz-db]

Superseded: the fixtures are now distributed into the PRs that fix the behaviour they prove, so each PR carries its own tests and no PR commits a golden that records a bug.

• split/keyed_edit, split/keyed_twoblock, split/multifile, split/positional -> bundle: route config sync edits to the block that defines them #6117
• split/keyed_remove, split/isolation -> bundle: remove split config sync elements from every block #6135
• split/keyed_rename -> bundle: write config sync key renames as a key rewrite #6134

The stack now starts at #6117.