Fix contextless 'Not Found' error logging on startup, bump to 0.4.5

[Bre77]

Intent

• Fix contextless error logging that produced a repeating bare [Teslemetry] Not Found log with no indication of what failed (npm homebridge-teslemetry 0.4.4, reported by a user)
  • Root cause: platform.ts's didFinishLaunching handler caught the account-discovery API chain (metadata() -> products_by_type()) with a single this.log.error(error?.data?.error ?? error). tesla-fleet-api's _request() rejects with { status, data } on any non-OK HTTP response, so a 404 logs literally just the string "Not Found" - no operation name, no status code, nothing.
  • Fix: metadata() and products_by_type() now each have their own .catch() that logs the operation name, HTTP status, and error body (data.error), falling back to the full error object for non-API-shaped rejections (e.g. network failures). Matches the ${op} failed: ${status}: ${data.error} logging pattern already used in vehicle.ts/energy.ts.
  • Reproduced by mocking metadata() to reject with {status: 404, data: {error: "Not Found"}} against the compiled dist/platform.js and confirming the current code logs bare "Not Found"; confirmed the fix logs Teslemetry metadata request failed (status 404): Not Found instead.
  • Same corrected pattern applied to products_by_type() failures (e.g. a 500).
  • This is a stopgap fix on the legacy teslemetry branch. The root cause was already fixed properly in the new (private, unpublished) monorepo plugin; this port keeps npm users unblocked in the meantime.
• Library update assessment: tesla-fleet-api pinned at ^0.2.0 is already the latest published version (0.2.0, published 2024-07-21) - no newer release exists, so no dependency bump was made or needed.
• Version bump: 0.4.4 -> 0.4.5 in package.json.

What Changed

• src/platform.ts: split the single .then(..., errorHandler) at the end of the metadata/products discovery chain into per-call .catch() handlers with contextual messages; downstream logic (accessory creation, registration) is unchanged, just reindented under the new nesting.
• package.json: version 0.4.4 -> 0.4.5.
• AGENTS.md (new): documents the multi-branch publish model and the tesla-fleet-api {status, data} rejection shape, so future error-logging fixes in this repo follow the same pattern.

Risk Assessment

Low. The change only affects the .catch() branches of the startup account-discovery chain - the success path (accessory creation/registration) is untouched logic, just re-indented. No dependency version changed. Verified with tsc --noEmit, eslint --max-warnings=0, and npm run build, all clean.

Testing

• npx tsc --noEmit - passes.
• npm run lint - passes with --max-warnings=0.
• npm run build - passes.
• No test suite exists in this repo. Did a smoke-level sanity check instead: imported the compiled dist/platform.js, constructed TeslaFleetApiPlatform with mocked homebridge log/api objects, and drove didFinishLaunching through four scenarios:
  1. metadata() rejects with {status: 404, data: {error: "Not Found"}} -> logs Teslemetry metadata request failed (status 404): Not Found (previously bare Not Found).
  2. products_by_type() rejects with {status: 500, data: {error: "Internal Server Error"}} -> logs Teslemetry products request failed (status 500): Internal Server Error.
  3. metadata() rejects with a plain TypeError("fetch failed") (non-API-shaped, e.g. network failure) -> logs Teslemetry metadata request failed: TypeError: fetch failed instead of status undefined: undefined.
  4. Happy path (metadata()/products_by_type() resolve, empty scopes/products) -> no error logs, registerPlatformAccessories still called correctly.

Publishing remains manual via publish.sh - that step is the captain's, after merge.

Full narrative / original brief

STOPGAP fix for the published HomeBridge plugin (npm homebridge-teslemetry 0.4.4), which builds from this repo's teslemetry branch, not the default dev branch.

A user reported the plugin failing with only a bare [Teslemetry] Not Found log line repeating, with zero context about what failed. That defect was root-caused and fixed in the new monorepo plugin (contextless error logging on a streaming/config-update failure path), but the monorepo plugin is private/unpublished, so npm users run this legacy code. This PR pushes the fix here as a stopgap, together with a library-update assessment (tesla-fleet-api is already at latest), and bumps the package version to 0.4.5.