Migrate downgrade-blocked route to dynamic routes

[MelvinBot]

Explanation of Change

This migrates the subscription downgrade-blocked screen from the legacy backTo query-param navigation pattern to the dynamic routes system, as part of [BT-152] Migrate Settings - Security/Wallet/Subscription.

Of the routes listed in the issue, the assignee's analysis concluded that only SETTINGS_SUBSCRIPTION_DOWNGRADE_BLOCKED is eligible for migration (the others cannot be migrated). The migrate-to-dynamic-route skill operates on a single route, so this PR scopes to that one route.

What changed:

• Added a DOWNGRADE_BLOCKED entry to DYNAMIC_ROUTES in src/ROUTES.ts (path downgrade-blocked) with the five screens that open it registered as entryScreens, and removed the old static SETTINGS_SUBSCRIPTION_DOWNGRADE_BLOCKED route (which used getUrlWithBackToParam).
• Replaced the screen constant SUBSCRIPTION_DOWNGRADE_BLOCKED with DYNAMIC_DOWNGRADE_BLOCKED in src/SCREENS.ts, and updated the linking config, navigator param list, modal stack binding, and the SETTINGS_TO_RHP relation accordingly.
• Renamed SubscriptionPlanDowngradeBlockedPage.tsx → DynamicSubscriptionPlanDowngradeBlockedPage.tsx. The page now derives its back target with useDynamicBackPath(DYNAMIC_ROUTES.DOWNGRADE_BLOCKED.path) and passes it to Navigation.goBack(backPath) instead of relying on a backTo param.
• Updated all five call sites to navigate via createDynamicRoute(DYNAMIC_ROUTES.DOWNGRADE_BLOCKED.path) instead of ROUTES.SETTINGS_SUBSCRIPTION_DOWNGRADE_BLOCKED.getRoute(...).

Why: dynamic routes derive the return destination from the actual navigation stack rather than a serialized backTo URL param, which is the direction the codebase is standardizing on for RHP screens. The eslint.seatbelt.tsv count change is an automatic baseline tightening from removing one getUrlWithBackToParam usage.

Fixed Issues

$ #83363
PROPOSAL:

Tests

// TODO: The human co-author must fill out the tests you ran before marking this PR as "ready for review"
// Please describe what tests you performed that validates your changed worked.

• Verify that no errors appear in the JS console

Offline tests

// TODO: The human co-author must fill out the offline tests before marking this PR as "ready for review".

QA Steps

// TODO: The human co-author must fill out the QA tests you ran before marking this PR as "ready for review".
// Please describe what QA needs to do to validate your changes and what areas do they need to test for regressions.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

[codecov]

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/ROUTES.ts	20.64% <ø> (+0.01%)	⬆️
src/SCREENS.ts	100.00% <ø> (ø)
...igation/linkingConfig/RELATIONS/SETTINGS_TO_RHP.ts	100.00% <ø> (ø)
src/libs/Navigation/linkingConfig/config.ts	76.92% <ø> (ø)
...scriptionPlan/SubscriptionPlanCardActionButton.tsx	0.00% <ø> (ø)
...ttings/Subscription/SubscriptionSettings/index.tsx	0.00% <ø> (ø)
...workspace/DynamicWorkspaceOverviewPlanTypePage.tsx	0.00% <ø> (ø)
src/pages/workspace/WorkspaceOverviewPage.tsx	0.00% <ø> (ø)
src/pages/workspace/WorkspacesListPage.tsx	55.27% <ø> (ø)
...gation/AppNavigator/ModalStackNavigators/index.tsx	6.53% <0.00%> (ø)
... and 1 more
... and 12 files with indirect coverage changes