Use imports instead of inline fully-qualified names in the DSL compilers

[wu-sheng]

Use imports instead of inline fully-qualified names in the DSL compilers

CLAUDE.md bans fully-qualified class names written inline where an import would do, and names the
exact form found here:

Field declarations, method signatures, local variables, and generic type arguments should always
use the imported short name — private RemoteClientManager rcm;, not
private org.apache.skywalking...RemoteClientManager rcm;

Analyzer.java:242 was literally private javassist.ClassPool pool;. 44 sites across 14 files in
the four DSL modules: parameter and field types, locals, throws clauses, static calls, a class
literal and a method reference.

The part that needed care

Every site changed is a name the compiler resolves. Nothing resolved at runtime was touched.

That distinction is the whole risk. Javassist's compiler has no import statement — it resolves a
simple class name only against ClassPool.importedPackages, which holds java.lang and nothing
else. A fully-qualified name inside generated source is therefore mandatory, and shortening one
still compiles as Java, then fails when the rule is compiled. The same applies to anything handed
to Class.forName.

So this PR deliberately did not touch:

• FQCNs inside codegen string literals (MAL/LAL/Hierarchy generators)
• anything under code-templates-v2/*.ftl
• names resolved reflectively

The transform rewrote only lines containing no quote character. That is sufficient rather than
merely convenient: a Java string literal cannot span lines under JDK 11, so a line with no quote
cannot be inside one. Verified after the fact — git diff shows no changed line contains a quote,
and no .ftl is modified.

Simple-name collisions and in-file shadowing were checked before any import was added. There were
none, so no site had to be left qualified for ambiguity.

Documentation

Adds a short CLAUDE.md to code-templates-v2/. The rule already exists in the root CLAUDE.md,
but the templates are the weakest spot: they are not Java, so a reader editing one has no reason to
consult a Java style rule, and "tidying" an FQCN there breaks the OAP only at rule-compile time.

• 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 #.

No changelog entry: no behaviour change, no user-visible surface.