feat(tree-view): add trailing content slot to tree view item

[TaylorShane]

What this adds

A trailing content slot for si-tree-view-item. It lets you place your own content — a button, an input, a badge, a third‑party component — at the end of a tree row, after the label and icons, without it becoming part of the drag area.

<si-tree-view [items]="items">
  <ng-template let-item="treeItem" siTreeViewItem>
    <si-tree-view-item cdkDrag [cdkDragData]="item">
      <button type="button" slot="trailing" (click)="acknowledge(item)">Acknowledge</button>
      <si-tree-view-item *cdkDragPreview />
    </si-tree-view-item>
  </ng-template>
</si-tree-view>

The problem (current behavior)

Today si-tree-view-item has only one projection slot, and it lives inside the draggable region (.grab-area). That causes two issues when a row needs custom content and drag‑and‑drop:

1. Interactive content fights the drag. Anything you project (e.g. a number input) sits inside the drag area, so pointer gestures on it can start a drag instead of letting you use the control.
2. No clean place for side content. To put a control next to the item, you have to wrap the draggable in your own element. Because the thing being dragged is then a wrapper — not a si-tree-view-item — the tree's drop indicator (the blue insertion line) doesn't render and the row leaves a full‑height gap while dragging (see Before).

The fix (what changed)

Two small, coordinated changes in si-tree-view-item:

1. New trailing slot, rendered after the label/icons and outside .grab-area (the default slot now excludes [slot=trailing]).
2. .grab-area is now the drag handle. A drag can only start from the item's main content region, so anything in the trailing slot is inherently drag‑safe.

Together these let you put cdkDrag directly on the si-tree-view-item (so the tree's normal drop indicator works) while still having a spot for custom content that won't hijack the drag.

Behavior change

NOTE: For draggable tree items, a drag now starts only from the item's main content area, not from the trailing slot or the end‑icons region. This refines the still‑evolving tree drag‑and‑drop behavior; existing reorder/move flows that drag from the label are unaffected.

Why it's useful

Rows that combine an action/indicator with drag‑and‑drop are a common pattern (acknowledge/select toggles, counters, quantity inputs, status chips). Previously each consumer had to work around the single in‑handle slot with custom wrappers and CSS. This gives everyone a supported, drag‑safe extension point on the component itself.

Testing

• Added unit tests: trailing content renders outside .grab-area, and it is not inside the drag handle (so it can't start a drag); existing drag/placeholder tests still pass.
• Added a docs example (si-tree-view-trailing-content) demonstrating an interactive button in the slot alongside reorder drag‑and‑drop.
• Updated the tree‑view component docs with a "Trailing content" section.

Before / After

Before:

After:

Checklist

• Conventional commit (feat(tree-view): …) with the behavior change noted
• Unit tests added and passing
• Docs + example added

Live Preview

This probably isn't necessary and the existing si-tree-view-drag-drop-copy could incorporate this.

[CLAassistant]

All committers have signed the CLA.