_apply_literal_shield: /* or */ inside a LiveCode string literal is treated as a block-comment delimiter

[squid-protocol]

Summary

_apply_literal_shield (used by Mode D _slice_by_keywords, and elsewhere) mis-handles a /*
or */ sequence that sits inside a LiveCode string literal in a multi_style_live-family
file (livecode). The single-pass string-vs-comment alternation is supposed to let whichever
construct starts first at a position claim its whole span, but for at least one real corpus file
a /* inside "..." is still treated as a block-comment opener, blanking every line up to the
next */ -- including the end statements that close the enclosing handler.

Repro

language-crucible/data/livecode/livecode/revsaveasandroidstandalone.livecodescript (2183 lines):

• line 1191: filter tGenerated with "*/R.java" -- */ inside a string
• line 1423: filter tZipItems with "Android/*" -- /* inside a string

The handler addExternalFromFile (source lines 1398-1466) is extracted as
addExternalFromFile_[Truncated] with a body of ~786 lines (1398 to ~1951), swallowing
addExternalFromFolder, revMobileRuntimeFolder, and ~15 other handlers, because its own
end if / end repeat / end addExternalFromFile lines fall inside the bogus comment span.

This is the ONLY truncation across the entire 98-file / ~900-handler livecode corpus after
#2409/#2410 landed -- every other handler slices cleanly -- so it's a narrow shield edge, not a
Mode D design gap.

Scope

Confirm whether other multi_style_live languages (or any language whose comment set includes
/* */ alongside string literals that can contain */) hit the same shape. The fix is in the
shield's single-pass alternation ordering / the string-literal pattern for this family, so it
has a wider blast radius than one file and belongs in its own PR with a full Differential Scan.

Found by

#2409 / #2410 livecode Mode D routing pass (2026-08-29). Noted in
docs/self_scan/manual_verification.json's livecode function entry and
docs/language_status/livecode.md §9 as a known body-extent limitation that does not affect the
934/934 handler-existence verification.