Code Review

JS Fix (heatmap.js — both default and original templates)

The fix is correct. prepData() already resolves the current category order (clustering + toolbox filtering), so syncing ticktext/tickvals from those resolved values before recalculateTicks() runs is the right approach. The ordering matters here — the tick sync runs first, then recalculateTicks() may further downsample for dense heatmaps, which is consistent with how ticks worked before.

if (this.layout.yaxis.tickmode === "array") {
  this.layout.yaxis.ticktext = ycats;
  this.layout.yaxis.tickvals = [...Array(ycats.length).keys()];
}

Minor: tickmode guard is necessary but creates a subtle gap. When the heatmap is large (Python skips setting tickmode: "array" because y_px_per_elem <= 12 or x_px_per_elem <= 18), the fix doesn't apply. In that case, Plotly uses auto ticks derived from the y values passed to the trace, which prepData() already sets correctly — so this case likely works fine already. Worth a comment to document this constraint.

Duplication across two templates: The identical fix is applied to both default/src/js/plots/heatmap.js and original/assets/js/plots/heatmap.js. This is correct and necessary, but it means future changes need to be kept in sync across both files.

Python Tests (tests/test_plots.py)

The tests are well-structured and cover the four meaningful clustering configurations (both, neither, rows-only, cols-only). The key invariant test is particularly good:

assert ds["rows_clustered"][ci][cj] == data[orig_row_idx][orig_col_idx]

However, the tests don't cover the actual bug being fixed. The Python-side clustering data (rows_clustered, xcats_clustered, ycats_clustered) is computed at report generation time and validated correctly here. But the bug is in buildTraces() — a JS function that syncs layout ticks at render time. That code path is not exercised by these Python tests. The tests validate that the data flowing into the JS is correct, not that the JS uses it correctly for tick labels.

This is a common limitation when the bug is interactive/browser-side, but it's worth acknowledging: if the JS tick-sync code were accidentally reverted, these tests would still pass.

Test isolation concern (pre-existing issue, not introduced here): _verify_rendered asserts len(report.plot_data) == 1, which would fail if a prior test left data in report.plot_data. The new tests use unique id values ("heatmap_cluster", "heatmap_no_cluster", etc.) which helps with the second assertion but not the len == 1 check. Since the existing test_heatmap presumably passes in CI, there must be state reset happening somewhere — but it's fragile and worth investigating.

Summary

Suggested improvement: A comment in buildTraces() explaining why the tick update only applies when tickmode === "array" (large heatmaps use auto-ticks derived from trace data, which are already correct) would help future readers.