`create rest client` operation: `Response: mapping` clause is silently discarded at write time (not just missing from read-back)

[MendixMau]

Environment: mxcli (RnD/upstream, v0.16.0), Mendix 11.12.0/11.12.1 project.

Steps to reproduce:

create module ZZB;
/

create non-persistent entity ZZB."Routing" (
  "RoutingCode": String(100),
  "RoutingName": String(200)
);
/

create json structure ZZB."JSON_R10"
  snippet $${"routing_code":"RT-PCBA-001","routing_name":"Routing for PCBA line 1"}$$;
/

create import mapping ZZB."IMM_R10"
  with json structure ZZB."JSON_R10"
{
  create ZZB.Routing {
    RoutingCode = routing_code,
    RoutingName = routing_name
  }
};
/

create rest client ZZB."MESSlice" (
  BaseUrl: 'http://localhost:3001/api/mes/core/v1',
  Authentication: none
)
{
  operation "SearchRoutes" {
    Method: get,
    Path: '/routes',
    Query: (
      $page: integer,
      $pageSize: integer
    ),
    Headers: ('X-Tenant-Id' = 'demo-tenant-01'),
    Timeout: 300,
    Response: mapping ZZB."IMM_R10"
  }
};

Run mxcli exec script.mdl -p project.mpr, then mxcli describe rest client ZZB.MESSlice.

Expected behavior: The operation should be persisted with its Query parameters and its
Response: mapping binding to ZZB.IMM_R10, matching what was written.

Actual behavior: mxcli exec reports success (Created rest client: ZZB.MESSlice (1 operations)) with no warning. mx check passes clean (0 errors) — an operation with no
response mapping and no query params is still a structurally valid, if useless, REST
operation, so Studio Pro's validator cannot catch this. describe rest client shows:

operation SearchRoutes {
  Method: get,
  Path: '/routes',
  Timeout: 300,
  Response: none
}

Query is missing entirely and Response shows none instead of the mapping.

Verified by direct BSON inspection (2026-08-05) — this is two distinct bugs, not one:

• Query: — read-back-only bug. The operation's raw BSON (Rest$RestOperation) has a
  correctly populated QueryParameters array (page, pageSize, both
  Rest$RequiredQueryParameterUsage). The data is written correctly; describe simply
  doesn't print it.
• Response: mapping — genuine write-path data loss. The same operation's
  ResponseHandling field is stored as Rest$NoResponseHandling — not a mapping-based
  response handler. A full-project BSON scan confirms nothing anywhere references the
  ZZB.IMM_R10 import mapping unit except the mapping's own definition. The Response: mapping ZZB."IMM_R10" clause is parsed (exec doesn't error) but never actually applied to
  the operation's ResponseHandling — it's discarded, not just hidden from read-back.

Root cause (not yet diagnosed at source level): not diagnosed on either fork, and
reproduces identically. Given the split above, the fix has two independent parts: (1) the
describe/read-back layer needs to print QueryParameters for REST operations (same class of
bug as the DataGrid2 MicroflowSource read-back issue in #839), and (2) the operation-writer
statement handler for create rest client … { operation … } needs to actually build a
mapping-based ResponseHandling value from a Response: mapping Mod.Mapping clause instead
of defaulting to Rest$NoResponseHandling.

Severity: the Response: mapping half is silent data loss with real runtime impact — a
REST operation built this way will not parse its response body into project data at all, and
nothing in mxcli check, --references, mxbuild, or Studio Pro's error pane signals it.