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

### Submission requirements

- [x] I generated this issue with an agent that used `.github/agents/ado-aw.agent.md`.
- [x] 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:

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

Perform the configured task.
```

Run:

```bash
ado-aw compile workflow.md
```

Observed behavior:

```text
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:

```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.

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.

Written by the indexing model from the issue text.