input: Make the three input states one engine, keyed by kind - #2716

Twenty-one methods that only apply to one kind of input sat in the
shared `impl` block, each opening with a `debug_assert!` on the runtime
layout mode. `InputState::soft_wrap(false)` and
`EditorState::masked(true)` compiled, then panicked in debug and passed
silently in release.

Move each one into the `impl` block of the mode it belongs to, so the
compiler rejects it instead. The two multi-line modes share several of
these, so add a sealed `MultiLineMode` marker for `TextareaMode` and
`EditorMode` to bound one `impl` block on, rather than writing the
methods twice.

`toggle_masked` stays generic: the reveal button renders from the shared
path, and the toggle can only be switched on through `InputState`.

No call site needed changing, in the library, the stories, or the
examples, which is the evidence that nothing relied on the old runtime
check.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Overlay sync runs on every frame. It compared the popovers against
`format!("{:?}", …)` of their own content, so an editor with the
completion menu open re-serialised the whole item list — each entry with
its documentation — once per frame, per popover.

The snapshot it compared was just as expensive: it cloned the completion
and code-action item lists unconditionally, including on the early-out
path taken when no overlay is showing at all. Since `hide_context_menu`
only clears `open` and leaves the items in place, a closed menu kept
paying for a full clone of the list from the last time it opened.

Give the two menu states a revision the engine bumps when it swaps their
content, and key the popovers on cheap identity instead: the revision
for the menus, the anchor range for hover, `Rc` pointer equality for the
diagnostic. The snapshot now carries no content, and the item lists are
read only on the frames where they actually changed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Two calls in the edit path were reaching for the wrong annotation hook.

On blur the engine called `reset_annotations`, which drops the hover
popover *and* clears every decoration. Blur used to drop only the hover
popover, so clicking away now threw out decorations the application had
installed and never asked to remove. `clear_hover_state` is the hook for
this — its own doc says "when the pointer leaves or focus moves".

The other call lost its body during the same refactor, leaving

    if mask_changed {
    } else {
        M::adjust_annotations(..);
    }

where the taken branch used to clear the decorations. Masking rewrites
the whole document, so ranges recorded against the old text point at
nothing; `reset_annotations` is what that branch wants. Harmless today,
since masking is single-line and a single-line input holds no
decorations, but it read as if it handled a case it dropped.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`LayoutMode` answered two different questions: how many rows to show and
how to grow them, and what kind of input this is. The second one already
had an answer at the type level, so the two could disagree — and did:

    TextareaState::new(w, cx).auto_grow(1, 1)
    // compile time: TextareaMode, every multi-line method reachable
    // run time:     is_multi_line() == false

because auto-grow derived multi-line from `max_rows > 1`. Soft wrap
could be set on that state and silently do nothing, and the debug
assertions guarding the multi-line methods fired on a configuration that
was perfectly legal.

Move the kind onto `InputModeKind` as `MULTI_LINE` and `CODE_EDITOR`
associated constants and answer from there. `LayoutMode` keeps the row
counts, the growth policy and the code-editor extras, and loses its
`multi_line` fields along with the three predicates derived from them.
Where the layout still needs the distinction — auto-grow, indenting,
indent guides — the caller passes it in.

Also moves `indent_guides` and `tab_size` into the mode blocks they
belong to; they were the same debug-assert pattern one file over, missed
by the earlier pass. No `debug_assert!` on the input mode is left.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`InputModeKind` had grown to 29 methods, 28 of which existed only for
the editor, and they were two different things wearing one name: places
where the engine hands control back mid-edit, and plain reads of fields
the renderer cannot reach because it is generic over the mode.

Split the reads out into `InputExtras`, implemented on the extras type
itself, so they are ordinary methods on ordinary data:

    -M::decoration_layers(&state.extras)
    +state.extras.decoration_layers()

`()` implements it with empty answers, which is what a plain input and a
textarea have to say. Adding a field an editor renders now touches only
this trait, and leaves the engine's callbacks alone.

Three methods had no callers at all — `lsp`, `lsp_mut` and
`hover_popover`, all shadowed by inherent methods on `EditorState` —
so they are gone.

`hover_definition_style` and `hover_definition_hitbox` were associated
functions on `TextElement<EditorMode>` that never touched the element,
reached through a hop from the engine's trait. They move onto
`InputBaseState<EditorMode>` where their data lives.

29 methods become 19 callbacks plus 6 accessors. The remaining 19 are
genuine re-entry points; removing those means the renderer no longer
being generic over the mode, which is a separate change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`EditorState::new` took a language ahead of `window` and `cx`, so the
three states were built three different ways and the editor's was the
odd one out. The language is a property of the editor like folding or
line numbers are, not something its construction depends on.

    -EditorState::new("rust", window, cx)
    +EditorState::new(window, cx).language("rust")

All three now read `new(window, cx)`, with the rest set through
builders. `LayoutMode::code_editor` loses its argument for the same
reason.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`Input::focused_as` asked the caller to hand over the `AnyInputState` to
register while the element holds focus. Every caller passed a value the
type already determined — `Input<TextareaMode>` can only be
`AnyInputState::Textarea` — and the field being an `Option` made "do not
register at all" a reachable state that nothing wanted.

Derive it instead, through the UI layer's existing per-mode seam, and
drop the field, the builder and its three call sites. The `From` impls
on `AnyInputState` are the mapping; `OverlayMode::any_state` is how the
generic renderer reaches them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`Input` was generic over the mode, and so were `Sizable`, `Selectable`,
`FocusableExt`, `Styled` and `RenderOnce` on it. Of the twelve things it
does to its state, every one is a method the shared engine offers for
every mode; only three places actually needed to know which mode it was
— the overlay registry, the focused-input identity, and handing the
state to the frame as a child.

Twelve generic call sites paid for by three. Hold a three-variant enum
instead and dispatch, and none of it needs a type parameter:

    -pub struct Input<M: OverlayMode = InputMode> {
    -    state: Entity<InputBaseState<M>>,
    +pub struct Input {
    +    state: TextInputState,

`AnyInputState` could not serve, because its fourth variant is
`OtpState`, a different engine with none of these methods; forcing it in
would leave Otp as a no-op on half of them. `TextInputState` is the
narrower enum, with `AnyInputState` derived from it where the window
registry needs the wider one.

Three things follow. `Input` is one instantiation rather than three.
`OverlayMode`, `LspOverlays` and `LspSnapshot` are `pub(crate)`, since
nothing public is generic over the mode any more — which means
`InputBaseState` no longer appears in any public signature in
`crates/ui`, only in one `pub(crate) use`. And `OverlayMode::any_state`,
added a commit ago, is gone: the enum's own `From` impl replaced it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…rivate

`HighlighterUpdate` was `#[doc(hidden)] pub` while its only consumer,
`LayoutMode::update_highlighter`, is `pub(crate)` and both modules on
the path to it are private. It was never reachable from outside; the
`pub` said otherwise. Now `pub(crate)`, and the `#[doc(hidden)]` that
was hiding a name nobody could write goes with it.

`InputBaseState` is the opposite case: its doc comment claimed the name
was not part of the public API, and that is not true. The three states
are type aliases of it, and an alias is only as usable as the type
behind it — making it `pub(crate)` leaves `InputState` unable to do
anything, which the compiler confirms with `private_interfaces` on
every alias and accessor. Say what is actually true instead, and point
readers at the aliases.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Forty-eight items across the input module were `pub` while sitting
behind a private module path, so nothing outside the crate could name
them. The `pub` claimed an API surface that did not exist, and reading
the module gave no way to tell which items were genuinely public.

Restrict them to `pub(crate)`, and put `#![warn(unreachable_pub)]` on
the module so the next one is caught at the point it is written rather
than by a later audit. The mechanical part is `cargo fix`'s work; the
lint is what keeps it done.

Two `#[doc(hidden)]` attributes go with them: once an item cannot be
named from outside, hiding it from the docs is describing a name nobody
can write. Four test helpers lose their `pub` for the same reason.

Scoped to `input/`. The rest of the crate has about six more, left for
a separate pass so this one stays reviewable.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>