UI: fix usage records end date with local timezone

[Dogface2k]

Description

This PR fixes the Usage Records date range when the user enables the local-timezone preference.

UsageRecords.getParams correctly used the first selected date for startdate, but also used that same first element for enddate in the local-timezone branch. Any multi-day selection was therefore reduced to the first day after conversion to UTC. The non-local-timezone branch already used the selected end date correctly.

The local-timezone enddate now uses dateRange[1]. No API parameters, timezone-conversion behavior, pagination, or unrelated UI paths are changed.

A focused regression test covers a multi-day range with a non-zero UTC offset, a range crossing a daylight-saving transition, and the existing local-timezone-disabled behavior.

Fixes #13581

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

Not applicable.

How Has This Been Tested?

Validation results:

UsageRecords.spec.js
Tests: 3 passed, 3 total

Complete UI unit suite
Test Suites: 5 passed, 5 total
Tests: 178 passed, 178 total

The UI lint completed with no errors, and the production UI build completed successfully using the repository's pinned Node 16.20.2 runtime.

The request windows were also checked read-only against a CloudStack 4.22.1 environment. For a selected eight-day range, the valid unconverted and correctly converted windows each returned 2,800 records; the original one-day window produced by the wrong index returned zero records.

How did you try to break this feature and the system with this change?

The regression test uses Europe/London so the expected UTC values have a non-zero offset. A second range crosses the 2026 spring daylight-saving boundary to verify that the selected end date and its own offset are both used. The local-timezone-disabled branch is retained as a control to prove its existing start and end dates are unchanged.

The production diff changes only the array index used by the local-timezone enddate expression. The complete UI unit suite, lint, production build, and git diff --check all pass.