refactor(spec): add selectable legacy and structural editors

[Thien Trung Vuong (trungams)]

Summary

This PR puts the existing line-oriented editor and the new structural editor behind the same public Spec API. The legacy implementation remains intact, while the structural implementation uses the parser and tree API introduced in the previous PR.

Editor selection happens once when a spec is opened. There are no mode checks scattered through individual operations and no automatic fallback from one editor to the other. This PR also adds a curated set of real-world spec fixtures to exercise the structural implementation. Production continues to use the legacy editor until the rollout configuration is introduced at the top of the stack.

Motivation

Issue #214 calls for structural awareness when editing sections and conditionals. At the same time, azldev is stabilizing and we want an escape hatch during adoption. Keeping both implementations behind one facade gives projects a controlled migration path without changing the public editing API.

Changes

• Add a private editor interface and constructor.
• Keep Spec as the unchanged public facade.
• Preserve the legacy visitor and line-oriented implementation.
• Add the structural implementation for section, tag, search, patch, and changelog operations.
• Preserve current-main release and provenance behavior.
• Keep structural visitors fully structural; macro bodies remain opaque to tag traversal.
• Preserve sequential search/replace overlays that temporarily pass through an unbalanced conditional state.
• Add curated real-world fixtures and deterministic parser/edit stress coverage.

Validation

• mage build
• mage unit

The cumulative stack was mechanically rebased onto eb9fb3f and revalidated. The complete rollout was also exercised against the full Azure Linux structural render corpus and the default-legacy E2E suite.

Known limitations

Macro preservation during section and subpackage removal is added by the next PR. The structural editor does not evaluate conditional expressions, so content after a wrapper's %endif cannot always be attributed to a section declared inside that wrapper. There is intentionally no automatic fallback between editors.