[yhoonkim]

PR Description

Fixes #9836.

When a tick (or rect-based) mark has an explicit size and its x/y
encoding uses a timeUnit field, config.<mark>.timeUnitBandPosition —
and bandPosition set on the field — were silently ignored. The tick was
always centered at the bin midpoint, which misaligned it with a bar on
the same encoding when e.g. timeUnitBandPosition: 0 was configured.

Root cause

rectPosition (in src/compile/mark/encode/position-rect.ts) dispatches
to two branches:

• rectBinPosition — honors timeUnitBandPosition via getBandPosition,
  and routes through the *_offsetted_rect_start/end fields.
• positionAndSize — used when size is set; hardcoded bandPosition to
  0.5 for the center ref (xc/yc) and never consulted
  fieldDef.timeUnit or getBandPosition({fieldDef, ...}).

So the second path produced xc: scale("x", 0.5 * datum["date"] + 0.5 * datum["date_end"]) regardless of the configured band position.

Fix

In positionAndSize, when the channel has a timeUnit field and no
secondary channel def, derive bandPosition via the same
getBandPosition({fieldDef, markDef, config}) helper used by
rectBinPosition, and pass it through to midPointRefWithPositionInvalidTest.

With bandPosition: 0, interpolatedSignalRef short-circuits to
{scale: 'x', field: <startField>}, placing the tick's center on the bin
start — matching the bar's center under the same config.

Verification

• Added unit test in test/compile/mark/encode/position-rect.test.ts
  covering tick + explicit size + timeUnitBandPosition: 0.
• End-to-end on the issue's repro, tick now emits
  xc: {scale: "x", field: "date"}, aligned with the bar.
• Full unit suite passes locally (6480 tests).

Checklist

• This PR is atomic (i.e., it fixes one issue at a time).
• The title is a concise semantic commit message.
• npm test runs successfully.
• For new features:
  • Has unit tests.
  • Has documentation under site/docs/ + examples. (bug fix, no docs needed)

[joelostblom]

Great to see this getting fixed, thank you! There is a somewhat related PR in #9827 which tries to address the fact that bandSize and size both exist for ticks. Would one of you have time to take a look and weigh in on if the fix is to expose bandSize as that PR suggests, or remove it from the docs as per my comment there?

[yhoonkim]

Superseded by #9838 — same commits, but the branch lives in vega/vega-lite directly now. Thanks for the review @kanitw!