[agent-issue]: support declarative Azure DevOps pipeline variables in workflow source

No source files are named. Start by tracing the front-matter parsing and compilation paths used by ado-aw compile workflow.md, then compare them with existing variable-groups: handling. Done means valid non-secret scalar mappings produce deterministic variables for standalone and 1ES targets, while compile, lint, and check cover collisions, invalid values, ordering, and lock stability.

Submission requirements

• I generated this issue with an agent that used .github/agents/ado-aw.agent.md.
• I reviewed the generated issue and confirm it is being filed directly in githubnext/ado-aw.

Problem summary

ado-aw supports importing Azure DevOps variable groups through variable-groups:, but workflow front matter cannot declare ordinary pipeline YAML variables. A top-level variables: mapping is rejected as an unknown field.

Some Azure DevOps platform features and pipeline extensions require variables to exist at pipeline compile time. Without source-level support, operators must add those variables directly to each generated pipeline definition after registration. That configuration is outside the workflow source and generated lock, can drift across definitions, and may be lost when a definition is removed and recreated.

This is distinct from runtime env: values and variable-group imports: runtime environment variables may be too late for compile-time pipeline behavior, while a variable group is unnecessary for non-secret feature flags and settings.

Reproduction details

Given a minimal workflow:

---
name: Compile-time feature configuration
target: standalone
variables:
  Platform.FeatureEnabled: true
  Platform.Mode: strict
engine: copilot
---

Perform the configured task.

Run:

ado-aw compile workflow.md

Observed behavior:

unknown field `variables`

The current workaround is to configure each Azure DevOps pipeline definition out-of-band after ado-aw enable, for example with az pipelines variable create. The Markdown source and generated lock provide no indication that the workflow depends on those settings.

Expected behavior: non-secret pipeline variables can be declared in workflow front matter and are emitted into the generated YAML:

variables:
- name: Platform.FeatureEnabled
  value: true
- name: Platform.Mode
  value: strict

Proposed next step

Add a source-level variables: field for non-secret Azure DevOps pipeline variables.

Suggested acceptance criteria:

1. Front matter accepts a mapping of variable names to scalar string, boolean, or numeric values.
2. Compilation emits deterministic Azure DevOps YAML variables for standalone and 1ES-compatible targets.
3. The compiler rejects collisions with variables it generates or reserves, with an actionable diagnostic.
4. Precedence and ordering relative to variable-groups: are documented and deterministic.
5. Secret literals are rejected or explicitly unsupported; documentation directs secret values to variable-groups:.
6. Values are serialized safely without accidentally interpreting untrusted template, macro, runtime-expression, or logging-command syntax.
7. compile, lint, and check tests cover valid declarations, invalid names and values, reserved-name collisions, and stable lock generation.
8. Documentation distinguishes compile-time pipeline variables from agent/runtime environment variables.