[Feature]: Make nested tool calls readable: outlines, clickable headers, smooth expand and collapse

[Vergil333]

Problem

Long agent turns are hard to read once you start opening tool calls. Inside "Worked for…", a
"Ran 5 commands" group and its expanded entries all render flat in the same color, so it is hard
to tell:

• which entries belong to which group,
• where one expanded entry's output ends and the next entry begins,
• that an open entry's header is what you click to collapse it.

Expanding and collapsing also snap: content appears or disappears in one frame and the rows below
jump. When the list is at the end, opening "Worked for…" with entries already expanded scrolls to
the bottom, which pushes the header you just clicked out of view instead of showing what is inside it.

Proposal (web timeline, so web and desktop)

Before/after recording (left: the current release, right: the proposal, on the same thread):

tool-call-outlines-before-after.mp4

• Structure: an expanded group gets a thin rail under its header icon, so its entries read as
  its children. An expanded entry becomes an outlined card, and its header is separated from its
  output by a divider. Hover is shown only on what clicking would toggle. Group headers get a chevron.
• Motion: opening a group, an entry, or a "Worked for…" fold grows the content in over 200ms.
  Closing shrinks and fades a static snapshot of what was on screen, so the list and its scroll
  maintenance see the final layout immediately. It runs only for the toggle you just made, never on
  scroll or remount, and respects reduced motion.
• Scroll: at the end of the list, opening something keeps following the end only until the
  clicked header reaches the top, so a tall fold shows its start. If that leaves the end, the
  "Scroll to end" pill appears as it would after a manual scroll.

Performance

Nothing animates continuously. Transitions exist only during a toggle, and the click itself
costs about 15–18ms in a dev build. To keep rows below an animating row moving in the same frame,
it extends the existing @legendapp/list patch: nested lists report their resize to the outer
list immediately rather than a frame late.

Questions for maintainers

1. Is this direction OK for the timeline?
2. Would you take it as one PR (one problem: nested tool calls are hard to read and jumpy to
   toggle), or split into structure / motion / scroll anchoring?
3. Mobile has its own timeline. Should a matching change be part of this or a follow-up?

The implementation is ready on a branch and I can open the PR once the direction and scope are agreed.