[Bug] Added ResizeObserver to update VA payments pagination on zoomed or mobile screens

[1Copenut]

Are you removing, renaming or moving a folder in this PR?

• No, I'm not changing any folders (skip to TeamSites and delete the rest of this section)

Summary

• A ResizeObserver was added to the Your VA Payments table pagination to ensure pagination links do not exceed the width of their container.
• Steps to reproduce bug are detailed in issue #95236
• This solution was the best one because it maintains the current default of 10 pagination links, but uses a Web native ResizeObserver to update the number of pagination links when the container width falls below 640px. This provides a better experience for users on mobile devices or who prefer to zoom their layouts in to 200, 300, or 400%.
• BMT team II. We own the maintenance of this product.
• No flipper in use

Related issue(s)

• PR closes [a11y-defect-3]: Your VA Payments table pagination should not extend outside the viewport when zoomed to 300% or more va.gov-team#95236

Testing done (TBD)

• Describe what the old behavior was prior to the change
• Describe the steps required to verify your changes are working as expected
• Describe the tests completed and the results
• _Exclusively stating 'Specs and automated tests passing' is NOT acceptable as appropriate testing
• Optionally, provide a link to your test plan and test execution records

Screenshots (TBD)

Note: This field is mandatory for UI changes (non-component work should NOT have screenshots).

	Before	After
Mobile
Desktop

What areas of the site does it impact?

Code is localized to the Your VA Payments view.

Acceptance criteria

Quality Assurance & Testing

• I added an e2e test that loads a large amount of mock data and asserts the ResizeObserver fired correctly
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Linting warnings have been addressed
• Documentation has been updated (link to documentation *if necessary)
• Screenshot of the developed feature is added
• Accessibility testing has been performed

Error Handling

• Browser console contains no warnings or errors.
• Events are being sent to the appropriate logging solution
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)

Authentication

• Did you login to a local build and verify all authenticated routes work as expected with a test user

Requested Feedback

(OPTIONAL) What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?

I would appreciate reviewers checking this feature locally using their preferred browsers and OS as time permits. This is a case where some users have a lot of payments and the pagination table was too wide for the container.

[1Copenut]

Added clarifying comments for code optimization and how some defaults came to be.

[1Copenut]

I opted to split the ResizeObserver into a custom hook to take advantage of useCallback() caching and prevent unnecessary re-renders. If there's value in raising this up to a higher "helpers" folder, LMK.

[1Copenut]

Went ahead and ran a window.ResizeObserver check even though MDN shows wide availability. Figured it couldn't hurt to be defensive for older browsers or devices.

[1Copenut]

In the original issue, we started seeing issues when the container width fell below ~500 pixels with 10 pagination links. I didn't want to have a random magic number in the code, so I fell back on the USWDS breakpoint that was closest to this number: https://designsystem.digital.gov/utilities/height-and-width/