Support reordering custom runners and custom metrics sources

[Kyome22]

Context of Contribution

• Bug Fix
• Refactoring
• New Feature
• Localization (new language or translation update)
• Others

Summary of the Proposal

Custom runners and custom metrics sources can now be reordered by dragging their rows in Settings, and the new order is persisted.

• UserInterface: both sections are wrapped in a List and use onMove, which brings the standard drag handle and drop animation. The custom runner row is extracted into CustomRunnerRowView.
• Model: new actions CustomRunnerSettings.onMoveCustomRunnerRow and CustomMetricsSettings.onMoveCustomMetricsSourceRow, backed by RunnerService.move(fromOffsets:toOffset:) (rewrites CUSTOM_RUNNERS.json and reloads the bundle list) and CustomMetricsService.moveSources(fromOffsets:toOffset:) (rewrites CustomMetricsConfiguration.sources and emits a configuration change).

Minor changes that come with it:

• The frame image reordering in the custom runner editor now goes through a reusable SortableViewModifier built on draggable / dropDestination, replacing the old DropDelegate.
• RunnerService.save(customRunner:with:) is renamed to add(customRunner:with:) so it reads as the counterpart of delete(customRunner:) / move(fromOffsets:toOffset:).
• Runner.displayText: Text becomes Runner.formatted: String, so the row views decide how to render it.
• New CriticalEvent.sortingCustomRunnersFailed for the failure path of the reordering.
• Store Action cases and their test cases are put back in the same order, so a case and its tests stay easy to pair up.

Tests: 169 tests pass locally (LocalPackage-Package scheme, macOS arm64). The new actions and the two new service methods are covered.

Reason for the new feature

The order of custom runners and custom metrics sources is the order they appear in the runner picker and the metrics bar, but until now it was fixed to the order in which they were added. The only way to move an item was to delete it and add it back — for custom runners that means re-importing every frame image. Users who register several runners or several JSON sources hit this quickly.

onMove on a List is a stock SwiftUI API, so the maintenance cost is limited to the two service methods that rewrite the persisted order, both of which are unit tested.

Checklist

• I have read the CONTRIBUTING.md and agree to follow it.
• This PR does not contain commits of multiple contexts.
• The diff is minimal — no unrelated refactors, whitespace churn, or drive-by cleanups.
• Code follows proper indentation and naming conventions.
• Layering follows the LUCA architecture: no logic in DependencyClient, no logic in UserInterface views, no Asset/String Catalog references from Model.
• Implemented using only APIs that can be submitted to the App Store.
• Localization PRs only: Every translated string in this PR was hand-crafted by a human translator. No machine translation or LLM output was used. See CONTRIBUTING.md → Localization.

Related Issues

close #59