fix(core-flows): filter reservations by line item in createOrderFulfillmentWorkflow (#16136)

Fixes #16135

**What**
Renames the `variables` key of the `get-reservations` remote query in `createOrderFulfillmentWorkflow` from `filter` to `filters`, and adds a changeset (patch bump for `@medusajs/core-flows`).

**Why**
`RemoteQuery.fetchRemoteData` only recognizes the arg names `filters`, `context`, and the pagination options — any other arg is silently dropped. Because the query passes its `line_item_id` constraint under `filter` (singular), the constraint never reaches the module, and since the entry point is queried without ids, `take` is set to `null`. Every fulfillment creation therefore executes `listReservationItems({}, { take: null })`, fetching and hydrating **every reservation item in the database** and then using only the entries belonging to the fulfilled line items (via `buildReservationsMap`).

Results are functionally correct, so this went unnoticed, but the cost scales with the total number of reservations. On our production store (~286k reservation items from per-location reservations across 75 stock locations), each fulfillment creation seq-scans the full table and blocks the Node.js event loop for ~50 seconds, during which the API process serves no other requests. Details and evidence in #16135.

**How**
One-character fix: `filter` → `filters` in the `useRemoteQueryStep` call, so the `line_item_id` filter is pushed down to the inventory module query.

**Testing**
- Verified against production data via a patched `@medusajs/core-flows` (pnpm patch with this exact change): fulfillment creation drops from ~50s to well under a second, and `pg_stat_user_tables` shows no further full scans of `reservation_item`.
- The fulfillment flow behaves identically otherwise: `buildReservationsMap` already keyed by `line_item_id`, so downstream steps (`prepareFulfillmentData`, `prepareInventoryUpdate`) receive the same reservations for the fulfilled items as before.

Author: andrewgreenh

.changeset/order-fulfillment-reservations-filter.md

@@ -0,0 +1,12 @@
+---
+"@medusajs/core-flows": patch
+---
+
+fix(core-flows): filter reservations by line item in createOrderFulfillmentWorkflow
+
+The get-reservations query in `createOrderFulfillmentWorkflow` passed its
+`line_item_id` constraint under the variables key `filter`, which the remote
+query layer does not recognize (it only honors `filters`). The constraint was
+silently dropped and every reservation item in the database was fetched and
+hydrated on each fulfillment creation, blocking the event loop for tens of
+seconds on stores with large reservation tables.

packages/core/core-flows/src/order/workflows/create-fulfillment.ts

@@ -521,7 +521,7 @@ export const createOrderFulfillmentWorkflow = createWorkflow(
         "location_id",
       ],
       variables: {
-        filter: {
+        filters: {
           line_item_id: lineItemIds,
         },
       },