[Tests] Cover the bulk operations status table formatting

[github-actions]

WHY are these changes introduced?

Reviewing Main tests runs from 2026-09-24T00:32Z to 2026-10-01T00:32Z found ten failed runs, but no actionable flake left to fix:

• src/cli/commands/version.test.ts subprocess timeouts accounted for nine of the ten (windows Node 22, windows Node 24, macos Node 22). Open PR Stabilize version, profile, and package cache tests #8669 already replaces those ts-node subprocesses with in-process capture, so fixing it here would duplicate that work.
• The remaining failure, conf-store.test.ts > runs the task as usual when the cache is populated but outdated (ubuntu Node 26), ran on stable/4.8 and is already fixed on main by merged PR [Tests] Fix flaky outdated rate-limit cache test #8705.

No run in the window had an earlier failed attempt, so with the flake list exhausted this closes a coverage gap instead.

The text-mode table in status-result.ts (added in #8568) had no direct coverage. renderBulkOperationStatusResult was only exercised for JSON output and the not-found error, leaving the count abbreviation thresholds, the operation ID shortening, the date columns, and the download-link fallback unasserted.

WHAT is this pull request doing?

Adds four tests to result.test.ts covering the table rows that shopify store bulk status renders without an --id:

• Count abbreviation at each threshold, including the boundaries at 1000 and 1000000 and the 999999 case that formats as 1000.0K.
• The shortened operation ID, status, and both date columns for a completed operation.
• The fallback from url to partialDataUrl, with an empty finished date while the operation is unfinished.
• An empty results cell when neither download link is present.

Assertions use expect.objectContaining on the renderTable rows so each test pins only the cells it is about, leaving column styling free to change.

Validation on Linux x86_64 / Node 26.1.0: all 64 store test files pass, plus lint and type-check. Shuffled ordering (--sequence.shuffle) passed five consecutive runs, and the forks pool passed. Reverting each behaviour under test fails the matching assertion, confirming the tests would catch a regression.

The originally failing Windows and macOS runners are not reproducible locally, so cross-platform behaviour is confirmed only by CI on this PR. These tests assert pure string formatting and mock the UI layer, so they carry no platform-specific timing or filesystem dependency.

How to manually test your changes?

shopify store bulk status --store <your-store>

Post-release steps

None.

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes
• I've considered analytics changes to measure impact
• The change is user-facing — I've identified the correct bump type (patch for bug fixes · minor for new features · major for breaking changes) and added a changeset with pnpm changeset add