Cube live brush draws temporal histogram targets in the physical unit, not epoch-ms #128

Problem

During a cube cross-filter (live brush), the client rebuilds the delta of a histogram or histogram2d target from the cube counts. For a temporal target column, it builds the bin centers and the [lo, step, n] edges in the physical unit of the column, not in epoch-ms. The server sends epoch-ms.

• Datetime("us"): the values are 1000x too large, so the bars are outside the date range and are not visible.
• Date: day numbers are read as milliseconds after 1970, so the axis shows 1970-01-01.
• Hover bands use the same wrong edges.

With the default live_brush="auto", the commit sends only a cube_request and no selection request. So the wrong delta stays on screen after mouseup.

Reproduction

cache=True source with four figures: a numeric histogram as the brush source, and three targets:

• add_histogram(x="t") on Datetime("us")
• add_histogram(x="d") on Date
• add_histogram2d(x="t", y="b")

Brush 0.2 to 0.6 of the source. Compare with the same gesture and live_brush="off" (server delta):

The counts are correct (y sum 1194 in both modes). Only the x unit is wrong.

Cause

Nothing refuses a temporal target: Histogram.get_cube_target_spec and Histogram2D.get_cube_target_spec have no dtype gate, and the engine gives temporal target dims a unit (contract G, only Datetime("ns") and Time are refused). The client copies unit into the target dims, but only fvLineEnvCells uses it (fvPhysicalToEpochMs). histDeltaFromCounts and hist2dDeltaFromEntry in runtime/cube.js use dim.domain as it is.

Fix direction

In histDeltaFromCounts (the grouped histogram path also uses it) and hist2dDeltaFromEntry, map the centers and the edges through fvPhysicalToEpochMs(v, dim.unit) when dim.unit is set, as fvLineEnvCells does. For Date, the server floors the centers to whole days (_physical_to_temporal_series casts to Date), so the day unit needs the same floor to draw the bars where the server draws them.

Found in the review of #119.