Fix LAL segmentId/spanId extractor statements; delete dead DSL code and correct the kernel's docs

[wu-sheng]

This PR carries two things: a LAL bug fix found while writing missing coverage, and the dead-code
and documentation cleanup that led to it.

Fix LAL segmentId and spanId extractor statements, which never worked

Found by writing the coverage below — the DSL surface existed, was documented by the grammar, and
had never been executed.

LALParser.g4 declares three trace-writing extractor statements:

traceIdStatement   : TRACE_ID   valueAccess typeCast? ;
segmentIdStatement : SEGMENT_ID valueAccess typeCast? ;
spanIdStatement    : SPAN_ID    valueAccess typeCast? ;

LALScriptModel.FieldType has all three (TRACE_ID, SEGMENT_ID, SPAN_ID, TIMESTAMP), and
LALBlockCodegen's output-setter table already carried setSegmentId and setSpanId — which
LogBuilder implements. Only LALScriptParser.visitExtractorStatement was missing two branches,
and its if-chain ended with an unchecked assumption:

// before — ctx.ifStatement() is null for any unhandled alternative
return (ExtractorStatement) visitIfStatement(ctx.ifStatement());

So a rule containing segmentId parsed.seg as String failed at boot with
NullPointerException: Cannot invoke "LALParser$IfStatementContext.condition()" because "ctx" is null — naming a construct the rule does not contain. That fall-through is why two of the three
statements stayed unimplemented: the failure never pointed at them.

Both branches are added, and an unmatched extractor statement now reports its own rule line.

No existing behaviour changes. LogBuilder.init() copies trace id, segment id and span id
directly from the log's metadata, and skips that copy only when a rule already set them:

if (this.segmentId == null) { this.segmentId = tc.getTraceSegmentId(); }

No shipped rule sets them, so every log record already gets these fields — which is exactly why
the gap went unnoticed.

Coverage, none of which existed

METADATA_TRACE_GETTERS (traceId / traceSegmentId / spanId) had no rule and no test
exercising any entry, in either direction. The harness could not express it either — the fixture
builder only understood trace-id, and the execution test had no expectation for these fields.
Both are extended, then used:

case	covers
trace-context-read	reads all three via log.traceContext.* into tags
trace-write-all-three	writes all three from an extractor, overriding metadata
trace-segment-override	segmentId alone — the exact shape that threw

trace-segment-override failed with the NPE before the parser fix and passes after, so the tests
demonstrably catch the defect rather than merely accompanying it.

---

Delete dead DSL code and correct the shared kernel's own documentation

Follow-up to #13972. No behaviour change: deletions of unreferenced code, plus comment and
javadoc corrections. 86 insertions, 506 deletions.

Dead code

Each verified to have no reference in Java, resources, SPI files, codegen string literals or
FreeMarker templates — the last two matter, because a class named only from a .ftl looks dead to
every tool (OALDebug is exactly that case, and is not touched here).

deleted	why
DslContentHash	byte-identical, zero-caller twin of the live ContentHash, which has 29 call sites and a test. Its javadoc told the reader to consolidate toward the dead copy
oal-rt/.../v2/registry/ (3 classes)	a second, divergent answer to what MetricsHolder already does; zero references outside its own package
LogAnalyzerFactory	empty class, sole occupant of its package, one occurrence repo-wide
MALCodegenHelper.RUN_VAR, MALExprCodegen.getVarCount(), DslYamlLineIndex.empty()	no callers

The kernel was asserting consumers it does not have

This is the part worth reviewing. Three classes in server-core carried javadoc justifying their
placement by naming users that grep disproves:

• DSLClassLoaderManager — "the meter / log compile paths reach for INSTANCE". Neither
  analyzer module references it. MAL and LAL accept a plain ClassLoader and narrow through
  BytecodeClassDefiner, so neither ever names it.
• LogDataDebugDump — "Lives in core so LALOutputBuilder implementations can render their
  cached LogData". Zero core references; its one caller is in log-analyzer.
• DslContentHash — "…can share one implementation" / "scheduled for consolidation in a
  follow-up". The follow-up never happened and nothing shared it.

A false rationale in a shared kernel is not a stale comment, it is a standing instruction to put
more things there. Each now states what the call sites support.

The converse was also missing: OALDebug, OALDebugRecorder and DebugHolderProvider are
OAL-specific and by symmetry belong in oal-rt, where MAL's and LAL's equivalents live. They
cannot move — dsl-debugging/pom.xml declares no oal-rt dependency, so the recorder
implementation would lose sight of them. Nothing said so, leaving it looking like carelessness.
Now recorded on all three.

Residue from #13972

Fourteen sites. The worst contradicts the code beside it: LALClassGenerator stated "No
LineNumberTable … an absent attribute reports an unknown line, which is honest" eleven lines
above the call that attaches one, and above a test from the same PR asserting every method carries
one. git show confirms it survived as a two-word substitution inside the very hunk that added
those calls.

Also: a javadoc block orphaned when a method was inserted between it and its owner; a {@link} to
a method that PR deleted; escapeJava / sanitizeName / COMPANION_SAM_LINE_IN_CLASS named in
comments after being removed; a log.debug("MAL YAML line index …") in a class now serving four
DSLs; and a hierarchy javadoc example missing the line number the code actually emits.

Two small corrections

• MALClassGenerator now uses MALCodegenHelper.GATE_HOLDER_FQCN instead of shadowing it with an
  identical local literal. The constant read as dead only because of the shadow; LAL uses its
  equivalent at six sites.
• setYamlSource gains the @Deprecated its LAL and Hierarchy counterparts already carry — it was
  the only one of the three giving callers no migration signal while its own delegate target was
  deprecated.

CLAUDE.md: why generated source is fully qualified

Javassist's compiler has no import statement. It resolves a simple class name only against
ClassPool.importedPackages, initialised to java.lang and nothing else; widening it needs
ClassPool.importPackage, which is pool-wide mutable state and is never called here. So generated
source must fully qualify everything, java.util.Map included, and the project's
no-inline-fully-qualified-names rule applies to hand-written Java only. Shortening an FQCN inside a
codegen string or a .ftl compiles as Java and then fails at runtime — worth stating, since the
rule reads as universal.

• Explain briefly why the bug exists and how to fix it.
• If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes #.
• Update the CHANGES log.