feat: Add Enterprise/Core retention policy support to update_database (supersedes #56)

[jstirnaman]

Summary

Supersedes #56. That PR is from a fork with maintainer edits disabled, so this branch carries the same work, synced with main and with the review findings resolved.

Adds retention-period support to update_database for InfluxDB 3 Core and Enterprise, and merges the v1.3.0 changes from main (test infrastructure, error-handling, Cloud Serverless/Clustered support).

Review findings addressed

• [P1] Restore Clustered and Cloud Serverless update paths. The original branch predated the Cloud Serverless/Clustered work, so its updateDatabase switch dropped those cases. Merging main reinstates them; update_database now validates all five product types and routes each correctly.
• [P1] Core/Enterprise update contract. Verified against the InfluxDB source and a live Core 3.9.3 instance: the endpoint is PUT /api/v3/configure/database with retention_period as a humantime duration string (for example "60d") — not PATCH, and not a retention_period_ns field. The code was already correct; the CHANGELOG, README, tool description, and code comments were not. They now match the contract.
• [P2] formatRetentionPeriod data loss. A sub-day period rounded down to "0d", which marks all data for immediate deletion. It now emits whole days when evenly divisible, otherwise whole hours, and rejects periods shorter than one hour.

Verification

• New unit tests assert the exact PUT payload, the day/hour formatting, and the 1h-not-0d regression (8 tests).
• New gated integration test creates a database, updates its retention, and cleans up against a live Core instance. Run locally against Core 3.9.3: passing.
• A manual PUT … "60d" returned HTTP 200 on Core 3.9.3.
• npm run build, npm run lint, and the protocol tests pass.

Notes

• Updating retention on Core requires v3.2.0+. The static Core docs still say retention is immutable; that documentation lags the v3.2.0 release. Verified working on 3.9.3.
• maxTables / maxColumnsPerTable remain Cloud Dedicated/Clustered only; they are ignored (with a warning) on Core/Enterprise.
• Updated the build-run-core-enterprise skill, which previously stated update_database was unavailable for Core/Enterprise.
• Testing this PR also revealed [High priority] retentionPeriod loses precision past ~104 days (nanoseconds as JS number) #60

[jstirnaman]

CI fixes pushed (65b1aed)

Both failing checks are addressed.

Version consistency check — was failing because the CHANGELOG top heading was ## [Unreleased] while package.json/config.ts were 1.3.0.

• Bumped to 1.4.0 (minor: new backward-compatible retention feature) across package.json, package-lock.json, and config.ts.
• Promoted the CHANGELOG section to ## [1.4.0] - 2026-06-05.
• Reproduced the exact CI check locally: all three now report 1.4.0.

Integration tests (Cloud Serverless) — the update_database sets a retention period (Core/Enterprise) test ran in the Cloud Serverless job and failed at create_database (isError: true). Retention update via update_database uses the v3 API path, which Core/Enterprise support but Cloud Serverless (v2 bucket API) does not.

• Gated the test to core/enterprise via INFLUX_DB_PRODUCT_TYPE. It still runs on the Core job (which passed) and now skips on the Cloud Serverless job.
• Verified: vitest list shows the test under core and skips it under cloud-serverless.

Formatter — added a repo-local .prettierrc.json (prettier defaults: 2-space, double quotes, printWidth 80). The repo had no local prettier config, so npm run format was inheriting an ancestor config and would reformat the whole tree. This commit pins the config and normalizes existing files to it.

Pipeline: npm run build, npm run lint, and npm test (25 passed, 6 skipped) all pass.