fix: ENGINE_VERSION genuinely reads package.json (telemetry reported 4.4.0 while on 4.5.0)

[thunpisit]

The bug

src/lib/server/telemetry/index.ts:50 was:

/** Engine version. Sourced from package.json at build time. */
export const ENGINE_VERSION = "4.4.0";

The comment was already making a claim the code did not honour — it is a hardcoded literal. package.json moved to 4.5.0 in #206 and the constant stayed behind, so every install with telemetry enabled has been reporting a version it is not running, silently, because nothing compared the two.

Why this one matters more than a stale string

engineVersion is the payload field that answers "can we drop support for 3.x yet?" (docs/TELEMETRY.md). It is also the input any future upgrade checker compares a published release against. A checker built on a constant that drifts would offer a fork an upgrade it already has — or hide the one it needs.

The fix

Import package.json directly. resolveJsonModule is already enabled in tsconfig.json, and Rollup inlines the single accessed property at build time. Verified in the emitted bundle (.svelte-kit/output/server/entries/endpoints/api/telemetry/cron/_server.ts.js): it carries the string literal "4.5.0", with no JSON parse and no file read on the Worker at runtime.

The test

src/lib/server/telemetry/engine-version.node.test.ts pins it three ways:

1. VALUE — the constant equals package.json's version.
2. SHAPE — bare semver. Telemetry groups on this field; a stray v prefix or build suffix would fragment the histogram silently.
3. SOURCE — the declaration contains no version-shaped string literal, and the module does reach package.json.

(3) is the one that matters. (1) alone is satisfiable by retyping the new number by hand, which restores the exact bug being fixed here. Both (1) and (3) were confirmed to fail against the pre-fix source before being committed.

Also refreshes the stale 4.4.0 examples in docs/TELEMETRY.md and the engineVersion doc comment in telemetry/payload.ts.

Gate

Check	Result
pnpm run check	0 errors (35 pre-existing warnings)
pnpm run lint	0 errors (55 pre-existing warnings)
pnpm run test	1117 passed / 1117 (1114 baseline + 3 new)
pnpm run build	✔
pnpm run guard:contract	OK — contract v1.0.0 floor holds
pnpm run guard:css	OK — 798 classes, +0 new

Follow-up

This surfaced while researching a one-click upgrade flow for /admin; that design proposal is filed separately. The dependency is direct: an upgrade checker cannot be built on a version constant that lies.