Hoist visitor-independent parse setup out of per-file LazyResult constructor

[alanzabihi]

Hypothesis

In Workload B, each of the 250 files creates a new LazyResult (lazy-result.js constructor). The constructor performs several steps that are identical across all files when using the same Processor: plugin normalization, Result construction, helpers object assembly, warning/message array creation.

Move per-Processor setup to a lazy-initialized cache on Processor:

1. Normalize plugins once on Processor, not per LazyResult
2. Create the helpers object template once, clone for each file
3. Pre-compute the plugin type checks (object vs function) once

The LazyResult constructor then only does per-file work: set the CSS string, root node, opts, and shallow-clone the cached helpers.

Editable surface

• lib/lazy-result.js — slim down constructor, use cached Processor data
• lib/processor.js — add lazy-init caches for normalized plugins and helpers template

What's different from prior work

• Cache Processor visitor preparation across files with identical plugin configuration #50 cached prepareVisitors (neutral — prepareVisitors itself is cheap). This caches the CONSTRUCTOR setup, which runs before prepareVisitors.
• Reuse LazyResult and MapGenerator instances across files in Processor.process #62 proposed pooling entire LazyResult instances. This is less invasive: just hoisting setup, not reusing instances.
• The constructor runs 250 times; each creates arrays, objects, and iterates plugins.

Expected impact

METRIC_B improvement of 3-5ms from eliminating redundant per-file constructor work across 250 files.

[alanzabihi]

Polyresearch approval: thesis #65.