Add function hover documentation

[Seddryck]

Goal

Add LSP hover support for Expressif functions so that users can inspect a function directly in the editor and see its signature and concise documentation without leaving the expression they are writing.

This is the third feature in the initial LSP roadmap, after syntax diagnostics (#15) and function-name completion (#16).

The feature should reuse the same function metadata introduced for completion rather than maintaining a separate source of function names, parameters, aliases, or descriptions.

Expected behavior

Hovering a known function such as:

@value | text-to-pad-right(10, "*")
         ^^^^^^^^^^^^^^^^^

should produce information similar to:

text-to-pad-right(length, character)

Pads the input text on the right until the requested length.

The exact presentation is client-dependent, but the server should return structured Markdown/MarkupContent suitable for standard LSP clients.

Scope

Implement an LSP hover handler that:

• identifies the syntax node under the requested cursor position;
• determines whether that node represents a known Expressif function call or function identifier;
• resolves the canonical function metadata through the shared function catalog introduced by Add function-name completion #16;
• renders the canonical function name and parameter list as a readable signature;
• includes the function summary/description when available;
• returns no hover result when the cursor is not over a supported function construct;
• remains independent of VS Code-specific APIs or rendering behavior.

The handler should rely on parsed syntax / source ranges to identify the function under the cursor. It should not scan the surrounding text for words that happen to match known function names.

Shared function metadata

Hover must consume the same reusable metadata abstraction as completion.

Conceptually:

Expressif.Syntax
      │
      ▼
syntax node at position
      │
      ▼
FunctionCatalog
      ├── canonical name
      ├── aliases
      ├── parameters
      ├── optionality
      ├── summary
      └── category/scope
             │
             ▼
         HoverHandler

The hover implementation should not introduce a parallel documentation model.

If #16 initially exposes only the subset of metadata required for completion, extend that abstraction so hover can retrieve parameter names, optionality, and the short description from the same authoritative Expressif source.

Function resolution

Hover should support canonical names and aliases when aliases are valid syntax.

For an alias, the returned documentation should make the canonical identity clear. A reasonable presentation is to show the canonical signature and optionally indicate the alias being used.

Unknown functions should not produce misleading documentation.

Signature rendering

A function signature should include, where known:

• canonical function name;
• parameter names in declaration order;
• a visible distinction for optional parameters;
• no invented parameter types when the metadata does not provide reliable type information.

For example:

text-to-pad-right(length, character)

or, for an optional parameter:

token(index, separator?)

The exact optional-parameter notation may be chosen by the implementation, but it should be consistent and covered by tests.

Hover content

The initial version should stay concise. It should contain:

1. the function signature;
2. the short function description/summary.

Parameter-by-parameter documentation may be included if it is already available cleanly through the shared metadata, but full reference documentation is not required for this issue.

The output should use LSP-supported Markdown or plaintext and should degrade cleanly in clients with limited Markdown support.

Cursor/range behavior

Tests should cover hovering:

• the beginning, middle, and end of a function name;
• a canonical function name;
• a supported alias;
• a function in a pipeline;
• a nested function call;
• a literal or parameter value that contains text equal to a function name;
• whitespace or an operator;
• an unknown function.

The returned hover range, when supplied, should correspond to the function identifier rather than the entire call or document.

Acceptance criteria

• The language server advertises and handles LSP hover requests.
• Hovering a known Expressif function returns its signature and short description.
• The function under the cursor is identified from parsed syntax/source ranges, not broad text matching.
• Hover works for functions in pipelines and nested calls.
• Canonical function metadata comes from the shared function catalog or equivalent abstraction used by Add function-name completion #16.
• Parameter names and optionality are rendered consistently when available.
• Supported aliases resolve to the appropriate canonical function metadata.
• Hovering literals, whitespace, operators, or unrelated syntax returns no function hover.
• Unknown functions do not return documentation for another function.
• Tests cover cursor-position boundaries, aliases, nested calls, and negative contexts.
• The feature is editor-agnostic and works through standard LSP clients, including the thin VS Code client from Add VS Code extension as thin LSP client #13.

Out of scope

• Signature help while editing arguments; this is the next roadmap feature.
• Type inference for parameter or return types.
• Runtime evaluation or previewing function results.
• Hover for variables, fields, literals, operators, predicates, accumulators, or other language constructs unless they are represented by the same function metadata abstraction and require no additional semantic model.
• Linking to external documentation pages.
• VS Code-specific hover UI.