fix(hydrogen): respect cartId arg in cartGetDefault

[andromia3]

Closes #3639.

Problem

`cartGetDefault` returns a function whose public type declares a `cartInput?: CartGetProps` parameter, with `cartInput.cartId` documented as "The cart ID" and `@default cart.getCartId()`. But the implementation ignored `cartInput.cartId` entirely:

```ts
return async (cartInput?: CartGetProps) => {
const cartId = getCartId(); // cartInput.cartId ignored
if (!cartId) return null; // <-- bails even when caller provided one
// ...
variables: {cartId, ...cartInput}, // spread masks it in the variables, but only if we get here
};
```

If `getCartId()` returns `undefined` (e.g. no cart cookie) and the caller passes `cartGet({cartId: 'gid://shopify/Cart/...'})`, the early return fires and the function yields `null` instead of fetching the cart the caller asked for.

Fix

One-line change: prefer the caller's `cartId` before falling back to `getCartId()`.

```diff

• const cartId = getCartId();

• const cartId = cartInput?.cartId ?? getCartId();
  ```

Why the existing test didn't catch it

There's already a test ("should return a cartId passed in") that passes `cartGet({cartId: '...'})`. It passes on the broken code because:

1. `getCartId: () => CART_ID` in the test returns a value, so `if (!cartId) return null` doesn't fire.
2. The spread `...cartInput` in the GraphQL `variables` object then overrides `cartId` with the caller's value, so the mock storefront happens to echo back the "correct" id.

The bug only manifests when `getCartId()` returns falsy — exactly the scenario in #3639.

New regression test

```ts
it('should use the cartId passed in when getCartId returns undefined', async () => {
const cartGet = cartGetDefault({
storefront: mockCreateStorefrontClient(),
getCartId: () => undefined,
});

const result = await cartGet({cartId: 'gid://shopify/Cart/c1-456'});

expect(result).toHaveProperty('id', 'gid://shopify/Cart/c1-456');
});
```

This fails on the old code (`result` is `null`) and passes after the fix.

Scope note

Other cart operations (`cartLinesAddDefault`, etc.) accept `optionalParams.cartId` via `CartOptionalInput` and use the same `{cartId: options.getCartId(), ..., ...optionalParams}` pattern, where the spread happens to override cleanly. They don't share cartGet's early-return problem, so they're left untouched in this PR.

Changeset

Patch bump for `@shopify/hydrogen` included.

[andromia3]

Follow-up commit pushed after a review pass through the full dependency path.

What I traced

1. All usages of cartGetDefault / CartGetFunction / CartGetProps — only `createCartHandler.ts:271` consumes it (exposed as `cart.get`), plus the existing tests and the re-export from `index.ts`. No internal caller depends on the old behaviour.
2. Full path through `createCartHandler` — `createCartHandler` wraps `getCartId` so it can return `undefined` legitimately (no cart cookie yet, no `cartCreate` called yet). This is the exact real-world scenario in ignored cartId in cartGetDefault #3639.
3. Real-world `getCartId` — `cartGetIdDefault` in `packages/hydrogen/src/cart/cartGetIdDefault.ts` reads the `cart` cookie and returns `undefined` when absent, confirming the null-return path is reachable in normal use.
4. Every existing test against `cart.get` — including `createCartHandler.test.ts:171` `"function get can provide overridable parameter"`, which passes the same `{cartId: '…'}` override. On the old code that test happened to work because `getCartId` was truthy (`c1-123`), so the early return didn't fire and the spread of `...cartInput` overrode `cartId` in the GraphQL variables. Traced it — still passes with both changes.

What I found during the trace

The one-line fix (`cartInput?.cartId ?? getCartId()`) doesn't cover one edge case: a caller that computes the cart id dynamically and passes `{cartId: maybeUndefined}`. In that case the local `cartId` is correctly resolved via `??`, but the `variables: {cartId, ...cartInput}` spread then overwrites `cartId` with `undefined` from the input, and the query goes out with `cartId: undefined`.

Added in the follow-up commit

• Swap the GraphQL `variables` spread order: `{cartId, ...cartInput}` → `{...cartInput, cartId}`. The resolved local `cartId` now always wins, while `country` / `language` / `numCartLines` / `visitorConsent` still come through from `cartInput`.
• New regression test (`"should fall back to getCartId when cartInput.cartId is explicitly undefined"`) that calls `cartGet({cartId: undefined})` and asserts the cookie cart id is returned. Fails on the old spread order, passes after the swap.
• Changeset updated to cover both fixes.

Scope note (unchanged)

Sibling cart operations (`cartLinesAddDefault`, `cartLinesRemoveDefault`, etc.) use a similar `{cartId: options.getCartId(), ..., ...optionalParams}` pattern, but none of them have `cartGetDefault`'s `if (!cartId) return null` early return, so they don't share this bug. Left out of scope here.