Enable full VSIX build/test lane in Azure DevOps (OneBranch) for GitHub CI parity

## Problem

Our current OneBranch/ADO path intentionally uses an inert `TF_BUILD` mode for VSIX projects to avoid missing desktop VSIX toolchain/package dependencies in the restricted build environment. This keeps ADO green for framework packaging, but it is not parity with GitHub CI behavior for VSIX validation.

Recent failure (`CS5001` in VSIX test projects under inert mode) confirmed that the current path is a compatibility fallback, not a real VSIX build/test lane.

## Goal

Add a **real Visual Studio extension (VSIX) build/test lane** in Azure DevOps so ADO validates the same VSIX surface that GitHub runners validate today, and so OneBranch failures reflect real extension health rather than inert-mode quirks.

## Scope

- ADO/OneBranch CI (non-official) should be able to build and run VSIX tests in a toolchain-complete lane.
- ADO/OneBranch official should support parity checks as appropriate for release confidence (at least build-level parity; test parity where feasible).
- Keep existing framework/package/release flow intact.

## Current State (for context)

- `src/vs-reactor/Reactor.VsExtension/Reactor.VsExtension.csproj` includes `TF_BUILD` guard rationale and inert fallback.
- `src/vs-reactor/Tests/Reactor.VsExtension.Tests/Reactor.VsExtension.Tests.csproj` and `src/vs-reactor/Tests/Reactor.VsExtension.SdkTests/Reactor.VsExtension.SdkTests.csproj` also use `TF_BUILD` inert path.
- OneBranch pipelines:
- `build/pipelines/OneBranch.CI.Reactor.yml`
- `build/pipelines/OneBranch.Official.Reactor.yml`
- shared steps: `build/pipelines/templates/reactor-build-steps.yml`

## Proposed Work

1. **Provision ADO agent/toolchain parity for VSIX lane**
- Ensure lane has Visual Studio extension development workload and VSSDK targets required by `src/vs-reactor` build/test path.
- Validate availability of all VSIX-related package/tool dependencies in the ADO environment/feed model.

2. **Add dedicated VSIX build/test job(s) in OneBranch CI**
- Build `src/vs-reactor/Reactor.VsExtension/Reactor.VsExtension.csproj` in non-inert mode.
- Run:
- `src/vs-reactor/Tests/Reactor.VsExtension.Tests/Reactor.VsExtension.Tests.csproj`
- `src/vs-reactor/Tests/Reactor.VsExtension.SdkTests/Reactor.VsExtension.SdkTests.csproj`
- Publish test results/artifacts on failure.

3. **Introduce explicit pipeline switch for inert vs real mode**
- Replace broad `TF_BUILD` implication with a clearer property/flag (e.g., `ReactorVsixInertMode=true/false`) controlled by pipeline lane.
- Keep fallback inert mode available for lanes that are intentionally toolchain-limited.

4. **Align command/property parity with GitHub runner lane**
- Document and enforce equivalent `dotnet` invocation knobs where practical (`Configuration`, CI props, restore behavior, filters).
- Capture and close known deltas between GitHub CI and ADO lane behavior.

5. **Document contributor guidance**
- Add a short section in `src/vs-reactor/TESTING.md` and/or `CONTRIBUTING.md` describing:
- which ADO lane runs real VSIX validation,
- when inert mode is expected,
- troubleshooting guidance.

## Acceptance Criteria

- [ ] ADO CI has at least one lane that builds VSIX projects in non-inert mode.
- [ ] ADO CI executes both VSIX test projects in non-inert mode.
- [ ] No `CS5001`/entry-point failures from inert fallback in the parity lane.
- [ ] Test results are surfaced in ADO with pass/fail parity expectations documented.
- [ ] Existing official packaging/signing/publish flow remains unaffected.
- [ ] Docs updated to describe lane behavior and parity expectations.

## Non-Goals

- Replacing GitHub CI as the primary VSIX validation lane.
- Changing public NuGet/OneBranch release governance flow.

## Notes

- Reference architecture/constraints: `docs/specs/056-visual-studio-embedded-preview.md`
- This issue is follow-up to recent inert-mode CS5001 fix (`OutputType` conditional under `TF_BUILD`) and is intended to remove reliance on inert mode for parity validation where feasible.