feat(tui): design anatomy-based plugin attachment API

Problem

TUI plugin slots currently enumerate fixed positions such as prompt.footer.end. This does not scale when a plugin needs to render relative to existing UI elements. Adding increasingly specific positional slots would keep expanding the API without describing the UI structure plugins attach to.

Proposed API

Publish a small anatomy tree of stable, named host parts and let plugins attach relative to those parts.

context.ui.attach("prompt.footer", {
  after: "location",
  render: () => <text>content</text>,
})

The same operation can support container takeover:

context.ui.attach("prompt.footer", {
  replace: "right",
  render: () => <text>custom footer</text>,
})

Placement is a correlated sum:

type Placement =
  | { at: "start" | "end" }
  | { before: Part }
  | { after: Part }
  | { replace: Part }

The anatomy should describe the footer that exists today, including its host-owned left side:

prompt.footer
├── left
│   ├── location
│   └── status
└── right
    ├── editor-context
    └── contributions

location and status occupy the same left-side region conditionally: the normal state shows the current location, while active operations show status/progress there.

Proposed host behavior

• Replacing a part suppresses attachments within that subtree.
• Suppression is visible in the plugins UI rather than happening silently.
• Ancestor replacement wins over descendant claims.
• At the same node, the most recently enabled plugin wins.
• User-hidden host parts retain their anchors so attached plugins can still render.
• Under width pressure, guest plugin content is hidden before host content.
• Plugins do not receive width queries; the host owns measurement and pressure policy.

Questions to grill

• What naming and compatibility guarantees do anatomy part IDs need?
• Should replace ship in the first version or follow relative attachment later?
• How should separators and gaps behave when host parts are hidden or replaced?
• Is most-recently-enabled ordering sufficiently predictable for conflict resolution?
• What diagnostics should plugins receive when an attachment is suppressed or references a missing part?
• Does the anatomy tree expose enough structure without coupling plugins too tightly to host layout?

Start by tracing the existing TUI plugin slots and the context.ui.attach entry point described in the issue. Work through the proposed anatomy tree and the listed replacement, suppression, ordering, width, and diagnostics questions; done means the API shape and compatibility behavior are agreed and documented well enough to implement.