folding: library declarations in .sv files produce misleading cross-line Declaration folds

[hongjr03]

Summary

library declarations (library-map syntax) written in a plain .sv file parse as errors, and slang's error recovery turns the pieces into multi-line "declarations" whose ranges bleed into following lines. Folding then reports misleading Declaration folds (e.g. a fold covering \nendlibrary).

Repro

File bad_lib.sv:

library lib;
  include "file";
endlibrary

Open it in the editor. The parse diagnostics report 4 errors:

expected member            @0..7   (`library`)
expected a declaration name @11     (after `lib;`)
expected member            @15..22 (`include "file";`)
expected a declaration name @41     (near `endlibrary`)

textDocument/foldingRange currently returns:

Declaration 31..42   // "\nendlibrary"

31..42 spans from the newline after include "file"; through the end of endlibrary — a range that makes no sense as a declaration.

With a second include line:

library lib;
  include "file";
  include "other";
endlibrary

we get Declaration 31..42 and Declaration 50..61 — again each range starts at a newline and swallows the next line's tokens.

Expected behavior

• In a plain .sv file, the library-map constructs should either parse as a LibraryDecl (and fold as FoldKind::Library via library_decl_srcs), or — failing that — error-recovered declarations should not produce cross-line Declaration folds that misrepresent the source.
• In proper library-map files (.map), the Library fold path exists and works; this issue is only about library syntax in .sv files.

Root cause

The ordinary SystemVerilog parse path does not recognize library-map grammar (library/include/endlibrary). The parser error-recovery synthesizes declarations whose range includes the surrounding newlines and subsequent tokens (HIR declaration_srcs mirrors those ranges, and folding reports them as-is).

Note: a duplicate-fold aspect of this case (each such declaration folding twice, once as an item and once as a one-element group) was already fixed in #325; what remains is the misleading cross-line range itself.

Suggested directions

1. Treat library/endlibrary as a LibraryDecl even outside .map files (parse-level), or
2. Suppress Declaration folds for error-recovered declarations (e.g. skip declarations whose range starts/ends inside trivia or which contain recovery tokens), or
3. Document that library syntax is only supported in .map files and leave folding as-is (not recommended: the current ranges are actively misleading).