Fix infinite category loading after in-flow workspace upgrade

[MelvinBot]

Explanation of Change

After migrating the money-request IOU steps to the dynamic-route system in #92161, the in-flow workspace Upgrade → Category path (self-DM → create manual expense → confirm → Category → Upgrade → Confirm → "Got it, thanks") started showing an infinite loading spinner on the Category step instead of the category list.

Root cause: the CATEGORIES branch of afterUpgradeAcknowledged in DynamicIOURequestStepUpgradePage navigated to the Category step with a hardcoded CONST.IOU.TYPE.SUBMIT IOU type. Before the migration, this navigation went through the page's backTo route, which CategoryField built using the original iouType; the hardcoded SUBMIT was only a fallback. The migration removed backTo, so the flow always used SUBMIT, which caused the Category page to resolve the wrong report/policy context — leaving policyID undefined so fetchData() never fetched categories and isLoading stayed true forever.

This change passes the original iouType to the category route, restoring the pre-migration behavior so the Category page resolves the correct policy and loads the category list.

Fixed Issues

$ #93228
PROPOSAL: #93228 (comment)

Verification

Verified on a brand-new account with no workspace: after completing the upgrade flow, the Category list loads with default categories and no infinite spinner.

Confirmation page	Upgrade screen	Workspace created	Category list (loaded)

AI checks run locally on the changed file: prettier ✅, lint-changed ✅, typecheck (tsgo) ✅, react-compiler-compliance-check ✅.

Tests

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

1. Sign in with an account that has no workspace.
2. Open your self-DM and create a Manual expense (enter an amount → Next).
3. On the confirmation page, tap Category.
4. On the Upgrade screen, tap Upgrade → Confirm → Got it, thanks.
5. Verify the Category list loads (categories or empty-state) and does not spin forever.

• Verify that no errors appear in the JS console

Offline tests

N/A

QA Steps

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

1. Same steps as Tests above, on staging, with an account that has no workspace.
2. Verify the Category list loads correctly after the workspace is created.

• Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

See the Verification section above.

[MelvinBot]

The failing ESLint check is unrelated to this PR — it's a pre-existing eslint-seatbelt baseline drift on main.

Analysis: All 466 reported errors are in one file, tests/unit/ReportSecondaryActionUtilsTest.ts, for the rule @typescript-eslint/no-unsafe-type-assertion. That file now has 466 errors of this type, but its seatbelt baseline allows only 450 (config/eslint/eslint.seatbelt.tsv:1821):

✖ 466 problems (466 errors, 0 warnings)
[eslint-seatbelt]: There are 466 errors of this type, but only 450 are allowed.

Evidence it's not from this PR:

• This PR's only change is a single line in DynamicIOURequestStepUpgradePage.tsx (iouType instead of CONST.IOU.TYPE.SUBMIT) — no type assertions added.
• ReportSecondaryActionUtilsTest.ts and eslint.seatbelt.tsv are byte-identical between this branch and current main; the only file differing between the two is the one-line fix above. So main produces the same 466/450 overage, and merging main won't resolve it.

Recommended remediation (separate from this PR): the seatbelt baseline for that file/rule needs to be updated from 450 → 466 (or the 16 newly-unsafe assertions in ReportSecondaryActionUtilsTest.ts fixed), ideally by whoever introduced the regression. I'm intentionally not bundling that unrelated baseline change into this category-loading bugfix.

All other checks (typecheck, Prettier, React Compiler, unit tests, Storybook, perf) passed. The remaining checklist failure is the human-completed PR Author Checklist.

[MelvinBot]

I can't fix this on PR #93252 — the failing ESLint check is a main-wide breakage, not caused by this PR, so pushing to this branch won't resolve it.

New evidence since my last comment: the identical ESLint failure is currently hitting other unrelated open PRs — #93251 and #93247 both fail with the exact same message:

✖ 466 problems (466 errors, 0 warnings)
[eslint-seatbelt]: There are 466 errors of this type, but only 450 are allowed.   @typescript-eslint/no-unsafe-type-assertion

All 466 errors live in tests/unit/ReportSecondaryActionUtilsTest.ts, whose eslint-seatbelt baseline allows only 450 (config/eslint/eslint.seatbelt.tsv:1821). This branch is byte-identical to current main except for the one-line fix in DynamicIOURequestStepUpgradePage.tsx, so main itself produces this same 466-vs-450 overage.

Why I'm not pushing a fix here:

• The fix (update the seatbelt baseline from 450 → 466, or resolve the 16 newly-unsafe assertions in ReportSecondaryActionUtilsTest.ts) is unrelated to this category-loading bugfix.
• It needs to land on main to unblock every open PR — fixing only this branch would leave Fix missing tax amount limit error after money-request route migration #93251, Fix: return to confirmation page after creating a category from the confirm step #93247, and others red, and would loosen the seatbelt ratchet inside an unrelated PR.

Path forward: a maintainer should push the seatbelt baseline correction to main (this looks tied to the eslint-seatbelt setup in #91911, the current main HEAD). Once that lands and main is merged into this branch, the ESLint check here will go green with no code change needed on this PR.

The only other failing check, checklist, is the human-completed PR Author Checklist. Everything else (typecheck, Prettier, React Compiler, unit tests, Storybook, perf) passes.

[huult]

@MelvinBot please close this PR

[huult]

@MelvinBot Please close this PR

[huult]

@MelvinBot Please close this PR