feat(data-grid): first-class column alignment API

[focus0802]

Problem

Data Grid has no first-class way to align a column. Today consumers hand-roll it with class names:

{
  accessorKey: "amount",
  meta: {
    cellClassName: "text-end",
    // Reaches into the component's internal DOM: the header content wrapper
    // is a private flex div, and headerClassName only lands on the <th>.
    headerClassName: "text-end [&>div]:w-full [&>div]:justify-end",
  },
}

Three problems with this:

1. The header content layout has no public handle. meta.headerClassName is applied to the <th>, but the header content is wrapped in an internal flex div (-ms-2 flex h-full items-center justify-between gap-1.5 in data-grid-column-header.tsx). Positioning the trigger inside the cell forces consumers to select internal DOM with [&>div] variants.
2. It couples consumer styles to internal structure. The [&>div] idiom recently caused a real bug: on resizable grids the same selector matches the column resize handle (also a direct div child of the <th>), and the compiled .\[\&\>div\]\:w-full>div (0,1,1) out-specifies the handle's .w-5 (0,1,0) — stretching the absolute handle across the whole header cell and swallowing every click. See fix(data-grid): prevent resize handle from covering header menu on end-aligned columns #120.
3. The recipe must be repeated per column (start / center / end each need their own class string), and skeletons need separate handling again.

Proposal

Add a semantic alignment field to the column meta contract, e.g.:

{
  accessorKey: "amount",
  meta: {
    align: "end", // "start" | "center" | "end"
  },
}

The component then owns the mapping:

• <td> / <th> get the matching text-* class;
• the header content wrapper gets the matching w-full + justify-* internally (no consumer selector needed);
• meta.skeleton alignment follows the same edge.

Open questions

1. One knob or two? A single align covers the common case (numeric columns right-align both header and cell). Separate headerAlign / cellAlign would allow e.g. a start-aligned header over end-aligned cells. Which is the right surface?
2. Interaction with existing headerClassName / cellClassName. Keep both as an escape hatch; explicit class names should still win over align-generated ones (or the contract should state the merge order).
3. Naming. align on meta vs. a top-level column field — meta seems right since TanStack keeps presentation data there, but worth confirming.
4. Scope. Both base and radix registries, docs, and an example (the c-* examples probably already carry the [&>div] idiom and could be migrated).

References

• fix(data-grid): prevent resize handle from covering header menu on end-aligned columns #120 — the resize-handle click bug caused by the current idiom
• registry-reui/bases/{base,radix}/reui/data-grid/data-grid-table.tsx — meta.headerClassName / meta.cellClassName merge sites
• registry-reui/bases/{base,radix}/reui/data-grid/data-grid-column-header.tsx — internal header content wrapper

[focus0802]

WIP implementation for review (not yet a PR): https://github.com/focus0802/reui/tree/feat/data-grid-column-align

Concrete choices made in the draft, so the shape is easy to push back on:

• Single meta.align knob ("start" | "center" | "end"), applied to header cell, body cells, and skeleton.
• Logical text-start / text-center / text-end on the cells; the header content wrapper gets w-full justify-* internally (no [&>div] needed).
• Explicit text-* utilities in headerClassName / cellClassName win over align; [&>div] layout utilities in headerClassName keep working through higher specificity.
• The th base string drops text-left + rtl:text-right in favor of a logical text-start default (identical rendering).
• Docs section + c-data-grid-1 balance column migrated as a demonstration; the other examples still use the old recipe and can follow once the shape settles.

[focus0802]

Follow-up visual contract from the local alignment implementation review:

For meta.align: "end":

• The header content wrapper should use w-full justify-end.
• The trigger should use neither -me-2 nor me-2.
• -me-2 makes the hover background extend into the resize-handler area and cover the separator line.
• me-2 leaves the trigger unnecessarily far from the column edge.
• The existing cell trailing padding should provide the visual gap before the resize handler.

The local implementation keeps relative z-20 only for interaction safety; it is not the spacing mechanism. Please add a regression covering the end-aligned trigger hover state so its background does not cover the resize separator.

This is separate from #120, which should remain focused on hardening the resize handle against consumer [&>div] selectors (w-5! / justify-center!).