Allow renaming a resource to a different case of its own name (#328)

[VirSanctus]

Part of #328 (case D)

Problem

A rename that only changes case fails:

$ rpk servers rename Srv01 srv01
Conflict: Server resource 'srv01' already exists.

RenameResourceUseCase refuses the rename if GetByNameAsync(newName) finds anything, and since names compare case-insensitively that lookup finds the resource being renamed. The Web UI rename dialog and the MCP rename_resource tool go through the same use case, so they fail the same way.

Fix

Only a different resource with the new name is a conflict now. The check looks through GetAllOfTypeAsync<Resource>() for a match that is not the resource being renamed (compared by reference, since both lookups return the same instances). As you suggested, renaming onto another resource's case variant is still refused, whatever its kind.

I compared by reference rather than skipping the conflict when GetByNameAsync(newName) returns the resource itself, because in a config that already holds Dup61 and dup61 that lookup returns the first one. rename Dup61 DUP61 would then succeed as a rename onto dup61's case variant.

The runsOn and connection rewrites already compare case-insensitively (#329), so they follow the new casing without changes.

Renaming a resource to exactly its current name used to fail with "already exists"; it now returns early and succeeds without writing anything. In the Web UI that means pressing Save in the rename dialog without editing the name no longer shows an error.

Tests

Five CLI tests in Tests/EndToEnd/ConnectionTests/RenameResourceTests.cs:

Test	Checks
rename_that_only_changes_case_updates_the_name	a case-only rename succeeds and re-cases the name
rename_that_only_changes_case_updates_runs_on_and_connections	dependants' runsOn and connection endpoints get the new casing
rename_onto_another_resources_case_variant_is_still_refused	same kind and different kind
rename_to_the_identical_name_leaves_the_file_unchanged	succeeds and leaves the file text unchanged
rename_is_refused_when_the_config_already_holds_a_case_variant	the Dup61 / dup61 config

The first, second and fourth fail on staging and pass with the fix. The third and fifth pass on both; they guard what must not change, and the fifth fails if the check is written as "skip the conflict when the match is the resource itself".

I also checked the Web UI by hand in the Docker image built from this branch: renaming Srv01 to srv01 in the dialog goes to the page for srv01, saving the dialog again without editing the name shows no error, and renaming it to OTHER01 while Other01 exists shows the conflict in the dialog.

Not included

• The loader question (reject or warn when a config already holds two names that differ only by case) is untouched; it is the open question in my last comment on [Bug]: del / rename leave dangling runsOn references and connections when the name is typed in a different case #328. In such a config every lookup still resolves to the first of the two, as before.

Interaction with #348

This merges cleanly with #348, and the CLI tests pass on the merge (383/383).

Local results

• CLI tests: 381/381
• MCP tests: 70/70
• Discovery tests: 260/260
• E2E tests: 106/106
• dotnet format --verify-no-changes: clean
• Build: 0 warnings, 0 errors

Checklist

• Linked GitHub issue ([Bug]: del / rename leave dangling runsOn references and connections when the name is typed in a different case #328)
• Approach validated (your reply on [Bug]: del / rename leave dangling runsOn references and connections when the name is typed in a different case #328)
• Small, focused PR
• CLI tests passing locally
• E2E tests passing locally
• Behaviour covered by tests
• YAML migration defined (if needed): not needed, no persisted shape changes

[Timmoth]

Amazing - thanks @VirSanctus !