fix(config): migrate deprecated keys in an inline [projects] scope

[worktrunk-bot]

Problem

for_each_config_table_mut — the scope walk behind every per-project deprecation rule — matched only Item::Table, for the projects container and for each entry inside it. TOML's two equivalent shapes therefore migrated differently:

[projects."example.com/org/repo".merge]
no-ff = true                                        # migrates to ff = false

[projects]
"example.com/org/repo" = { merge = { no-ff = true } }   # skipped

The skipped form is not merely left unmigrated. UserProjectOverrides's MergeConfig has ff and no no-ff alias, so the unmigrated key reaches serde at a path with no field, is dropped from the typed config, and the per-project non-fast-forward merge silently stops applying. An unknown-field warning may fire, but the setting is gone either way.

The rule reached inside an inline merge = { … } already — migrate_negated_bool_inline exists for exactly that — so the gap was the outer scope, one level up.

Solution

The walk now visits a projects container and a project entry in either shape. An inline entry is migrated through a table view and written back inline, and only when a rule reported a change, so an entry nothing touched keeps its formatting.

This covers every rule on that walk, not just merge.no-ff: switch.no-cd, the removed list.task-timeout-ms, and the [select] / [commit-generation] section renames. [ci] → [forge] is not among them — migrate_ci_doc reads and writes the document root directly, so it has no per-project scope in either shape.

rename_hook_key and remove_approved_commands_doc keep their own table-only traversals of projects — #4116 flags them as worth an owner-level look. They are left alone here: both move or delete whole items rather than rewriting a key inside a section, so the fix is not the same shape, and folding them into the shared walk is a larger change than this bug needs.

Testing

• test_migrate_no_ff_inline_project_scope — asserts both the migrated text and that the setting reaches the typed config (config.projects[…].merge.ff == Some(false)), which is the part that was silently lost.
• test_migrate_no_ff_fully_inline_projects_table — the projects container itself inline.
• test_migrate_leaves_unrelated_inline_project_keys_alone — an entry no rule touched keeps its formatting, and sibling keys in a migrated entry survive the table round-trip.
• test_warning_fires_iff_update_changes gains four rewritten entries covering the inline scope across merge.no-ff, list.task-timeout-ms, the [select] rename, and switch.no-cd, so the framework invariant is checked for the newly-reachable shapes too.

All four fail before the change. cargo test --lib passes apart from copy::tests::test_copy_dir_recursive_does_not_count_a_non_regular_file, which fails on main in this sandbox too (socket(AF_UNIX, …) is blocked). cargo clippy --all-targets and cargo fmt --check are clean.

Reported by @zach-hammad-vs from source inspection; the reproduction above confirms it.

Closes #4116 — automated triage

[worktrunk-bot]

Self-review. The migration behavior itself checks out — I ran the inline shapes
through migrate_content and compute_migrated_content, and the inline project
entry, the fully-inline projects container, and a dotted merge.no-ff = true
inside an inline entry all migrate and reach the typed config. Three points:

The changelog entry lists [ci] among the renames this walk covers, but
migrate_ci_doc never calls for_each_config_table_mut — it reads forge and
ci off the document root and writes there. Both
[projects."a/b".ci]\nplatform = "gitea" and its inline equivalent come back
byte-identical with no deprecation reported, so the entry promises a migration
that doesn't exist for that key.

migrate_inline_scope writes the migrated table back only when f returns
true, so a rule that mutates its scope table and then reports no change keeps
that mutation on the standard-table path and loses it on the inline one. None of
the five rules on the walk does that today. But migrate_section_doc already
computes its return from two independent outcomes (moved, dropped), and the
module's design rests on rules whose predicate and rewrite can't drift — this is
a new way for them to drift, silently and only in one shape. Worth stating as a
requirement on f where the contract lives.

test_migrate_leaves_project_entries_that_are_not_tables_alone doesn't pin what
its comment says it pins. result.contains("\"a/b\"") is implied by the
disjunct next to it, and neither checks the entry's value survived. For the
array-of-tables case, migrating the no-ff = true inside [[projects."a/b"]]
would satisfy both assertions — ff = false comes from the top-level [merge].

[worktrunk-bot]

affected tests (macos, advisory) is red on this head: integration_tests::switch_picker::test_switch_picker_prs_rows_survive_alt_x_removal panicked after 30s waiting for Loading open PRs to appear, with a blank picker frame on screen. Flake, not a regression — the required test (macos) job ran the same 4876 tests on this exact commit and reported 4876 passed, the advisory macOS job was green on the previous head, and the diff reaches only src/config/deprecation.rs and CHANGELOG.md, which that picker test does not exercise. Every required check and codecov/patch are green, so the red advisory job needs no rerun before merge.