v1.15.0

• Faster request dispatch. A logged route call is ~2.9x faster
  (measured in-process, APIRoot.call on a trivial route: 2.76us -> 0.90us).

  • LoggerHandler no longer builds the formatted log message when nothing
    would consume it. Every record reaching the root listener was fully
    formatted — timestamp, padded/truncated isolate and logger names, plus a
    Zone lookup for the current APIRequest id — and then discarded when no
    destination (logAllTo/logErrorTo/logDbTo/console) was configured,
    which is the default. This was ~1us per record, and a route call emits two
    (CALL> and RESPONSE>).
  • APIRouteHandler caches its CALL> message and RESPONSE> prefix. Both
    are fixed once a route is registered, but were re-interpolated per request
    (including stringifying the declared parameters Map).
  • APIRoot._callImpl no longer copies the path parts list just to read the
    first one.
  • APIServer.toAPIRequest no longer copies the query-parameters Map a
    second time.

• The routes builder now accepts config: on any/get/post/put/
  delete/patch/head, matching APIModule.addRoute. Previously an
  APIRouteConfig could only be set through addRoute, so per-route logging
  could not be turned off through the usual API:

  routes.get('ping', handler, config: const APIRouteConfig(log: false));

  Route logging is on by default and costs roughly 4x the rest of a trivial
  dispatch, so this is worth setting on hot routes.

• New benchmark/ suites, with layered breakdowns so a regression can be
  attributed rather than just observed. See benchmark/README.md.

  dart run benchmark/bones_api_benchmark.dart   # request path
  dart run benchmark/json_benchmark.dart        # JSON request/response
  dart run benchmark/db_benchmark.dart          # DB entity path
  

  They record that query parsing is well cached (~300x cheaper than parsing)
  and SQL generation is under a microsecond. JSON encoding already runs close
  to a bare dart:convert encode, and request bodies use dart:convert
  directly, so no JSON optimization came out of that suite.

• DBSQLMemoryAdapter now answers a select by ID with a direct lookup in the
  table Map, which is already keyed by ID, instead of scanning it. A miss
  still falls through to the scan, so results are unchanged.

  selectByID was O(rows) and is now flat: 7.8us -> 7.1us at 10 rows,
  9.7us -> 7.2us at 50, and 25.3us -> 7.2us at 400. This mostly speeds up the
  test suite and development, since the memory adapter is where those run.