Problem:

- annotation-usage-error and code-style-check are disabled.
- vim.inspect relies on a dummy self-assignment for docgen, and its help
  omits parameter and option details.
- LuaLS fallback types obscure iterator inference.
- Docgen hardcodes public function names and appends separately sorted
  files, leaving shared helpers under the inspector heading.

Solution:

- Enable annotation-usage-error and code-style-check, and fix misplaced
  annotations.
- Document vim.inspect's callable module directly, removing the dummy
  assignment. Describe its parameters, option defaults and process
  callback.
- Remove LuaLS iterator fallbacks, correct iterator signatures and check
  values that the improved inference identifies as optional.
- Parse callable modules, require bindings and parent module references.
  Derive public names and inherited function docs from these links,
  including missing help for vim.async.semaphore() and vim.version().
- Export vim.lsp.tagfunc directly with lazy loading and document its
  implementation instead of maintaining a wrapper.
- Group files in section_order, replacing append_only and merge_files.
  Merge declarations before sorting each section, placing shared helpers
  in the main vim section and keeping vim.inspect in alphabetical order.
- Add basic parser coverage for callable modules and module links.

AI-assisted

Problem: Expected text for interactive marks is in a separate json file
from the tutor file. When the tutor file is updated, line numbers
(potentially many) have to be updated in the json file. This is a
burden for maintenance and automatic testing.

Solution: Put the expected text inline in the tutor file, marked
with `[[]]`. Parse and remove the comments before opening the tutor
file so extmarks can be applied.

refactor(lua): add integer coercion helpers

Add vim._tointeger() and vim._ensure_integer(), including optional base
support, and switch integer-only tonumber()/assert call sites in the Lua
runtime to use them.

This also cleans up related integer parsing in LSP, health, loader, URI,
tohtml, and Treesitter code.

supported by AI

Problem:
If users delete a line containing extmark, it will move to the next
line, which could highlight the next line in an unwanted way.

Solution:
- Use `invalidate` field in `nvim_buf_set_extmark()` to prevent the
extmark from moving.
- Also save from "priority" hacking, since we can check if the extmark
  is valid in `nvim_buf_get_extmarks()` now.

Problem:
From https://matrix.to/#/!cylwlNXSwagQmZSkzs:matrix.org/$Ofj-TFIsEMbp0O9OhE8xuZSNi-nhRLtZTOgs6JRLNrs?via=matrix.org&via=gitter.im&via=mozilla.org

In lesson 2.6, users are asked to remove the second, forth and fifth
lines with `dd` command, then they are asked to undo twice to make the
text go back to original state. But after that, the mark ✗ appears
again, which confuses the user because they think they do something
wrong. This is a limitation with the current implementation, which is
based on line number only.

Solution:
Reimplement interactive marks as extmarks in Lua. This also make the
feature less fragile, as users can remove, add some arbitrary lines
without breaking the interactive marks.

Co-authored-by: Justin M. Keyes <justinkz@gmail.com>