)

## Problem

Autocompleting a string union literal type whose members contain `.` is
broken in the Deno LSP. Given:

```ts
type T = "foo.bar" | "foo.baz";
const x: T = "foo.b"; // completing here
```

Accepting the `foo.bar` suggestion produces a mangled result —
everything typed before the last `.` is forgotten. Plain `tsc`/VSCode
handle this correctly. Reported in denoland#28075.

## Cause

For a string union (`Types`) completion, TSC sets a per-entry
`replacementSpan` (covering the string contents) but does **not** set
`insertText`. Deno's `CompletionEntry::as_completion_item` only
constructed a `text_edit` when **both** the replacement span and
`insertText` were `Some`:

```rust
if let (Some(text_span), Some(new_text)) = (range, &insert_text) { ... }
```

So the edit was silently dropped, leaving the editor to apply its own
word-based replacement. Because `.` is a word boundary, only the text
after the last dot was replaced.

## Fix

When a `replacementSpan` is present but `insertText` is not, fall back
to the entry name as the inserted text — matching VSCode's TypeScript
integration (`insertText ?? name`). This makes the full string content
get replaced.

## Test

Added `lsp_completions_string_union_with_dot`, which asserts the
completion item carries a `text_edit` spanning the whole string content.
Verified it fails before the change (`text_edit` is `None`) and passes
after. The full existing `lsp_completions`/auto-import/registry
completion suite (28 tests) still passes.

Closes denoland/divybot#395
Fixes denoland#28075

Co-authored-by: divybot <[email protected]>
Co-authored-by: Divy Srivastava <[email protected]>