/**
 * Integration tests for the Coolify v4.2 GET-to-POST compatibility work (#292 / #296).
 *
 * That work was built by reading upstream's `routes/api.php` at v4.1.2, v4.0.0
 * and older betas, and shipped without ever being run against a pre-4.2
 * instance. These tests close that gap: on Coolify < 4.2 they prove the legacy
 * path is genuinely needed, and on >= 4.2 they prove POST is genuinely accepted.
 * Either way the suite asserts something real.
 *
 * **Every assertion here is side-effect free**, and deliberately so:
 *
 * - A method the router rejects executes no controller, so a real POST probe
 *   starts, stops and deploys nothing. That is the same property the fallback
 *   itself relies on.
 * - `/deploy` with a tag matching no resource routes successfully and then
 *   deploys nothing, isolating "was the method accepted" from "did anything
 *   happen".
 * - `/enable` is only ever called on an instance whose API is already on, where
 *   it is a no-op. **`/disable` is never called at all** — it would turn off the
 *   API this client depends on, and it proves nothing that `/enable` and
 *   `/servers/{uuid}/validate` do not already prove.
 *
 * That guarantee is downstream of the version compare being correct, which is
 * why `parseMajorMinor` returns a tuple — `Number('4.10')` is `4.1`, which would
 * classify a 4.10 instance as pre-4.2 and point state-changing probes at a box
 * that accepts them.
 *
 * Run with: npm run test:integration
 */
export {};