fix(analytics): get_analytics start_time/end_time filters returned zero rows

[cb1kenobi]

Summary

get_analytics returned an empty array whenever start_time or end_time was supplied. list_metrics(['custom']) was silently broken in the same way.

Root cause

hdb_analytics stores its primary key id as the compound array [timestamp, nodeId] (see resources/analytics/write.ts — storeMetric). But the read path was passing scalar timestamps as the bound for greater_than_equal / less_than / between conditions on id. Harper's key encoding sorts scalar numbers and arrays into different ranges, so a scalar bound lands past the array key space and the range iterator returns nothing. The response had been hiding this by post-processing result.id = result.id[0] before returning to the client, so users saw scalar ids in responses and naturally assumed they could filter on them directly.

Fix

Wrap each bound as a single-element array — e.g. value: [startTime]. Because [X] sorts before [X, anything] in the compound key ordering, this gives the correct inclusive lower bound and exclusive upper bound semantics against the [timestamp, nodeId] key space.

While I was in there:

• Collapsed the prior if (startTime && endTime) / else branching into two independent if blocks. The both-bounds case used to go through between (inclusive end); it now uses less_than (exclusive end), matching the single-bound branch. Since the old code returned zero rows in real use, no caller can have depended on the inclusive-end behavior.
• Switched the truthiness check from if (startTime) to != null so a 0 timestamp is accepted.
• Same one-line fix applied to listMetrics' customWindow cutoff condition, which was scalar against the same compound key.

Where to look

• The behavior change from between (inclusive end) to half-open [start, end) is the only semantic shift. Since the previous behavior was broken, this is a fresh choice rather than a regression — but worth a glance to confirm half-open is what we want for analytics queries.
• Two separate id conditions vs one between — I don't believe search.ts collapses two same-attribute primary-key conditions into a single range scan, but the cost is negligible for this read path. Flagging in case there's a known reason to prefer between.

Tests

• Added 5 unit tests covering get(): no time filter, startTime only, endTime only, both bounds, and startTime: 0 (the falsy-edge fix).
• Updated 3 existing listMetrics tests to assert the wrapped-array bound.

Cross-model review

Reviewed via Gemini CLI — no blockers; the one note was a pre-existing return-type looseness on get() (Promise<Metric[]> vs the actual async iterable when coalesceTime is set), which is out of scope.

Generated by Claude (Opus 4.7).

[claude]

Reviewed; no blockers found.

[kriszyp]

I am not sure I understand the necessity of using an array key. Scalar values can be ordered alongside array values with order-binary, they are just hierarchy ordered:
1 < [1,1] < 2
And if we just doing ranges, where does the failure come from?

[kriszyp]

From what I recall, I had needed to use between because the query optimizer wasn't smart enough to collapse greater_than_equal and less_than into a single range estimate and would therefore prefer a different secondary index as the initial index to drive the query, leading to long scan of data for entries matching the requested timeframe.