render_markdown_compat_mode workaround never applies to array-shaped result.lines (e.g. LSP provider)

[lukeorland]

Description

ui.lua's render_markdown_compat_mode workaround for the render-markdown.nvim "float is one line short" issue only triggers when result.lines is a single object with a .value field:

https://github.com/patrickpichler/hovercraft.nvim/blob/main/lua/hovercraft/ui.lua#L289-L298

local lines = result.lines or {}

if lines.value and self.config.render_markdown_compat_mode then
  -- HACK: ...
  lines.value = lines.value .. "\n "
end

contents = vim.lsp.util.convert_input_to_markdown_lines(lines)

However, the built-in LSP hover provider (hovercraft/provider/lsp/hover.lua) always builds and returns result.lines as a Lua array of strings (e.g. {"```python", "(function) def monotonic() -> float", "```"}), never as a single object with a .value key. lines.value on an array is always nil (only numeric keys are set), so this branch — and the whole compat-mode workaround — never actually fires for LSP hover content, even with render_markdown_compat_mode = true configured.

Practical effect: when using render-markdown.nvim, LSP hover popups render one line short, cutting off the last line of content (in my case, the actual hover text was fully hidden, appearing to render nothing beyond a language-icon header).

This is likely related to / compounds with #21 (content extraction bug) — after fixing that separately, this compat-mode gap became visible as the next blocker.

Suggested fix

Extend the check to also handle array-shaped lines:

if lines.value and self.config.render_markdown_compat_mode then
  lines.value = lines.value .. "\n "
elseif type(lines) == 'table' and #lines > 0 and self.config.render_markdown_compat_mode then
  table.insert(lines, ' ')
end

Verified locally that this makes render_markdown_compat_mode actually take effect for LSP hover content and fixes the missing final line when render-markdown.nvim is installed.