Remove unsafe Object.entries assertions in compoundParamsKey

[KJ21-ENG]

Explanation of Change

Remove both unsafe Object.entries input assertions in src/libs/compoundParamsKey.ts, the only changed file. Each existing result is now assigned to Array<[string, unknown]> before the unchanged chain. The compiler checks the already narrowed object input, and downstream values remain unknown. There are no support or test changes.

No intentional runtime behavior change. The accepted plan and exact diff preserve guards, enumeration frequency, filter/map/sort order, signatures, exports and serialization. The existing Jest suite and direct production probes cover recursive key sorting, array order, top-level undefined omission, nested undefined placeholders, frozen inputs, own enumerable string keys, nonplain objects and existing serialization failures.

The encoder retains the route key plus NUL delimiter and normalized JSON suffix. Native focus restoration splits at NUL; web/native pruning uses the route-plus-NUL prefix. Probes cover NUL in parameter strings, exact placeholder bytes and the existing collision between nested undefined and its placeholder string. Empty object/array and scalar normalization equivalences also remain. Keys are not collision-free; route keys still assume no NUL. The probe records an out-of-contract NUL route without extending that contract.

Target	Unsafe assertions before	After	Pending reduction
src/libs/compoundParamsKey.ts	2	0	2

Net pending warning reduction: 2; merged credit: 0. config/eslint/eslint.seatbelt.tsv matches the base, signed head and working tree. Read-only checks left it unchanged, so no restoration write was required; merge automation owns the eventual reduction.

Fixed Issues

$ #94739
PROPOSAL: #94739 (comment)

Tests

Fresh independent verification passed all seven focused kinds: target-zero, ESLint, changed-root TypeScript, executable tests, formatting/spelling, changed paths and diff hygiene. Evidence is for the unchanged reviewed candidate:

1. SEATBELT_READ_ONLY=1 SEATBELT_DISABLE=1 eslint --no-cache --format json src/libs/compoundParamsKey.ts: zero findings or suppressed messages.
2. checkChangedTypeScript(candidateRoot, 'tsconfig.json', ['src/libs/compoundParamsKey.ts']): complete authorized import-free target and applicable declarations, zero target/configuration diagnostics.
3. jest --runTestsByPath tests/unit/compoundParamsKeyTest.ts --runInBand --no-cache --watch=false with private output/cache paths: 20/20 existing tests passed. Installed resolver and exact source-map contents identify the real candidate target. 11 additional direct production boundary groups passed, including bigint/cyclic failures, functions/symbols, Date/RegExp, frozen inputs, enumeration, normalization and collision behavior. These are fresh counts; older review probe counts are historical.
4. oxfmt --check src/libs/compoundParamsKey.ts and one-file CSpell: passed; each checked the actual target. git diff --check HEAD and exact changed-path checks passed. All 542 fresh recorded environment content hashes, five local packages, dependency link, Node runtime and TSV remained unchanged. Historical environment hashes remain unavailable.

For repeatable local UI testing, perform the QA steps below in the development environment.

• Verify that no errors appear in the JS console

Offline tests

Not performed. On a previously loaded screen with a focusable input, disconnect the network, focus the input and move its caret, then navigate away and back through locally available history. Verify the expected screen and focus/caret restore without duplicate or stale history entries. Reconnect and repeat, checking for console errors. Run on web and native where the flow is available. This helper adds no network request or offline fallback.

QA Steps

Manual QA required; review first. This is production code used by router resolveCursorForReset and web/native focus capture, restoration and pruning. The exact diff only adds typed bindings for the same two enumeration results; guards, enumeration, chain order, serialization, delimiter bytes and exports stay unchanged. Exact-diff inspection, the existing production Jest suite and fresh boundary probes support preserved branches and outcomes. UI execution remains outstanding.

Proposed staging checks on supported web and native platforms:

1. Open a screen with a focusable input. Focus it, enter text and move the caret to the middle. Navigate to another screen and return through app history. Verify the original route/parameters and expected input focus/caret restore.
2. Repeat with two history entries for the same screen that carry different route parameters. Move backward and forward using each platform's available history controls. Verify each entry restores its own state without reusing the other entry's focus or cursor.
3. Leave the screen and reopen it with different parameters, then repeat the return flow. Verify stale focus state is not restored from a removed history entry. If focus cannot be restored because the previous input is unavailable, verify navigation still completes without a crash or console error.
4. Repeat the offline steps above. Check the JS console throughout. Automated normalization/collision probes and bigint/cyclic failure checks remain helper-level evidence, separate from these UI checks.

• Verify that no errors appear in the JS console

PR Author Checklist

Checked items below acknowledge the linked issue and written repeatable test steps, not execution of the proposed UI checks. Offline, High Traffic, platform, console, consumer UI and authenticated/unauthenticated deeplink checks remain unperformed. Screenshots are unavailable. This diff adds no code pattern, comment, app copy, CSS, asset, generic UI component, Storybook change, message-editing logic, form layout, feature or bug fix; related conditional acknowledgements are left unchecked as inapplicable. Existing unit tests were reused, with additional private verification probes. No merge of main after review is recorded.

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

None captured. The change has no visual diff, and web/native UI QA remains outstanding.