Fix/rest api openwebui integration

[amirdhs]

Fix REST/JSON collection filters: nresults, date ranges, sort order and a schema disclosure

Found while connecting the groupdav.php/openapi.json REST API to an LLM tool-calling client
(Open WebUI). Four independent bugs, all reproducible with plain curl. Two return HTTP 500 on
documented parameters, one discloses table schemas, and one makes it impossible to bound a response.

Each commit stands alone and can be dropped independently.

1. nresults was silently ignored without a sync-token

CalDAV::jsonIndex() computed the limit but only forwarded it inside the
if (isset($_GET['sync-token'])) branch, and addressbook, calendar and timesheet
additionally required $options['root']['name'] === 'sync-collection'. A REST client therefore had
no way to bound a collection listing and always received the entire collection serialized as
JsContact / JsEvent / JsTask objects.

GET /groupdav.php/addressbook/?nresults=5      before: 10 entries    after: 5 entries
GET /groupdav.php/addressbook/?sync-token=&nresults=5     unchanged: 5 + more-results

Both gates are relaxed. sync-collection semantics (more-results plus a new sync-token) are
unchanged, and its forced ascending order still applies.

2. addressbook and timesheet defaulted to oldest-first

Defaults were egw_addressbook.contact_id and egw_timesheet.ts_id, both ascending. Combined with
(1), a limited request returns the N oldest entries — a plausible-looking wrong answer rather than
a visible failure. Now contact_modified DESC / ts_modified DESC. infolog already used
info_datemodified DESC; calendar has no ordering support.

Shipped in the same commit as (1) deliberately: a row cap without a sensible order is worse than no
cap at all.

3. filters[start] / filters[end] returned HTTP 500 on infolog and timesheet

CalDAV::jsonIndex() converts these into a synthetic
['name' => 'time-range', 'attrs' => [...]] element under an integer key. The JSON branch of
infolog_groupdav::_report_filters() merged $options['filters'] verbatim into the column filter,
so the array became a column:

GET /groupdav.php/<user>/infolog/?filters[start]=2026-07-01&filters[end]=2026-08-01
-> 500  Invalid SQL: ... AND Array ...  Unknown column 'Array' in 'WHERE'

It now goes through the existing _time_range_filter() helper, as the CalDAV/XML branch already
did. Verified against real rows: a June window matches the tasks due in June, a July window matches
none, and a narrow window discriminates correctly.

Timesheet genuinely has no time-range support, so there the same element now raises a
JsParseException (422) with an explanatory message instead of building a bogus ts_0 column.
doc/openapi/timesheet.json documents this.

4. Unknown filter names disclosed the full table schema

Db::column_data_implode() embedded print_r($column_definitions) and the supplied values in the
InvalidSql exception message, and CalDAV::exception_handler() echoes that message to the client:

GET /groupdav.php/<user>/timesheet/?filters[start]=2026-07-01
-> 500, 3832 bytes containing every column of egw_timesheet with types and precisions

The arrays are still written to error_log() for debugging; only the exception message is now a
single line. The same request returns 76 bytes.

This is the only change in core framework code. It alters the exception message only — no
control flow — and fixes the disclosure once for every app rather than per handler.

Also included

• calendar silently ignored filters[search] and filters[linked].
  calendar_groupdav::_report_filters() had no Api\CalDAV::isJSON() branch, unlike the other three
  handlers, so REST filters (a plain name => value array, not CalDAV XML elements) all fell through
  to unknown filter --> ignored, while doc/openapi/calendar.json advertised both. Added
  jsonReportFilters().
  filters[linked] uses query['egw_cal.cal_id'] rather than sql_filter, because
  calendar_bo::search() deliberately overwrites $params['sql_filter'] from its own second
  argument. calendar_bo::search() accepts only one "query", so a free-text filters[search] cannot
  be combined with filters[linked]; that combination now reports a clear error rather than dropping
  one silently.

• filters[order] was unreachable on timesheet. Its column mapper rewrote order to
  ts_order, producing bug (4). Now passed through, restricted to an optionally table-qualified
  column plus an optional direction. so_sql::search() already sanitises order_by, so this only
  converts a silently mangled sort into an explicit 422.

• doc/openapi/*.json corrections. These descriptions are what an LLM client actually sees, so
  wrong ones directly produce wrong requests:

  • filters[start] / filters[end] declared "type": "datetime", which is not a valid JSON
    Schema type. Clients that map OpenAPI parameters onto function schemas pass it through
    verbatim, so the parameter arrives unusable and date filters are never sent. Now
    "type": "string" with "format": "date".
  • nresults was described as "Limit number of responses (only for sync-collection)", actively
    discouraging clients from sending it.
  • filters[order] is now documented for the four apps whose handlers read it (not calendar).
  • The filters[end] example read filters[start]=2026-02-01.
  • Accept is no longer required: true — it is an in: header parameter, and tool executors that
    forward only path and query parameters force a value that is then discarded. It remains in
    the spec as optional documentation.