Add an osTicket integration: list open tickets from its database

osTicket's own REST API only supports creating tickets, not listing or
reading them, so this reads osTicket's MySQL/MariaDB database directly
with a read-only user instead - the only integration in this app that
isn't a REST API. Joins the ticket, status, priority, department,
staff, team, and user tables, filtered to tickets in the "open" state
(status names are customizable per install, but that state flag isn't).

Surfaces per-ticket subject, priority, department, assignee, requester,
and osTicket's own overdue/awaiting-reply flags, plus a page at
/osticket and a Dashboard widget with open/overdue/awaiting-reply
counts.

Not verified against a live instance: unlike the HTTP-based
integrations, there was no way to fake a MySQL server to test against
in this environment, so the query is built from osTicket's published
schema but has never actually run against a real database. See
INTEGRATIONS.md for the read-only grant needed and further caveats.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

INTEGRATIONS.md

@@ -104,6 +104,50 @@ the dashboard views themselves load fine.
   it against a real Proxmox Backup Server yet. If a datastore comes back empty or with the wrong fields, tell us
   what your instance actually returned and we'll adjust.
 
+### osTicket
+
+- **Config fields:** Database host, Database port (optional, default 3306), Database name, Database username,
+  Database password, Table prefix (optional, default `ost_` — only needed if you changed it at install time)
+- **Auth:** a plain MySQL/MariaDB connection (host/port/database/username/password) — not HTTP, and not osTicket's
+  own API.
+- **Why this one reads the database directly:** osTicket's official REST API only supports **creating** tickets
+  (`POST /api/tickets.json`) — there is no documented endpoint to list or read existing ones (osTicket's own
+  developer docs say as much: *"For now, only ticket creation is supported..."*). Listing tickets therefore means
+  reading osTicket's own MySQL/MariaDB database directly, the same way osTicket's own admin panel does internally.
+  This makes it the only integration in this app that isn't a REST API.
+- **Actions used:** read-only — a single `SELECT` joining the ticket, status, priority, department, staff, team,
+  and requester tables for every ticket whose status is in the "open" state. Nothing here can create, update, or
+  close a ticket.
+- **Required access:** a MySQL/MariaDB user with **read-only (`SELECT`) access to the osTicket database only** —
+  never reuse osTicket's own application database user, which has full read/write access. Create one with
+  something like:
+  ```sql
+  CREATE USER 'homelab_manager'@'%' IDENTIFIED BY 'a-strong-password';
+  GRANT SELECT ON osticket.* TO 'homelab_manager'@'%';
+  FLUSH PRIVILEGES;
+  ```
+  (narrow the host part — `'%'` — to this app's actual server address if your MySQL/MariaDB setup allows it, and
+  make sure the database's own network/firewall rules allow that connection in the first place; this integration
+  connects over plain TCP, unencrypted, so it's meant for a same-host or same-LAN database, not one reachable over
+  the internet).
+- **What you get:** every currently-open ticket's number, subject, status, priority, department, assigned staff
+  member or team (or "Unassigned"), requester name/email, source, created/last-activity/due dates, and two flags
+  osTicket already tracks natively — **overdue** and **awaiting our reply** (i.e. the customer replied last and
+  nobody on staff has answered yet) — which are the two things most worth a glance on a dashboard.
+- **A reliability note on subject/priority specifically:** those two fields aren't columns on osTicket's main
+  ticket table — osTicket normalizes them into its dynamic custom-fields system, and reads them back here from
+  `ost_ticket__cdata`, a cache table osTicket's own admin panel also uses for ticket lists (faster than joining the
+  generic form-fields tables). osTicket's own GitHub issue tracker documents that cache occasionally going stale or
+  briefly missing right after a custom-field change; this integration's query is written so a ticket with no
+  matching cache row still shows up in the list, just with an empty subject/priority instead of being silently
+  dropped.
+- **Not verified against a live instance** — built from osTicket's own published database schema and developer
+  docs (table/column names, the ticket status `state` classification, and the cdata-cache mechanism all
+  cross-checked there), but this could not be run against a real osTicket database in this environment either (no
+  MySQL/MariaDB server was available to test against). If a query comes back empty, errors on a missing column, or
+  a field looks wrong, tell us what happened and we'll adjust — this one has had less real-world exposure than
+  every other integration listed here.
+
 ### phpIPAM
 
 - **Config fields:** phpIPAM URL, API app ID, App token