feat(security-issue-sync): optional reconciliation against ASF security dashboard

## Problem

`security-issue-sync` reconciles a single tracker entry against its GitHub
discussion, the inbound `` thread, and any `` fix
PRs. There is currently no mechanism to detect drift between the project's
own tracker and a **separate inventory of the same issues kept elsewhere** —
for ASF projects, that other source of truth is the
[ASF security dashboard](https://dash.security.apache.org).

When the two diverge — a CVE allocated in the tracker but missing from the
dashboard, an advisory published on the dashboard but the tracker still
showing the issue open, a reporter credited in one and not the other — the
divergence today is only caught by manual cross-referencing. That doesn't
scale and quietly rots over time.

## Proposal

Two pieces, in order:

1. **New substrate tool** — `tools/asf-dash-security`. Read-only client for
`dash.security.apache.org`. Pulls the per-project inventory of advisories
/ CVEs / reporter credit / fixed-version metadata into a normalized
in-memory record set that other skills can consume. Pure read (no write
API on the dashboard side anyway).

2. **Optional reconciliation step in `security-issue-sync`** — when enabled
by the adopter's project manifest, the sync skill performs a one-shot
comparison between the tracker entry and the matching dashboard record
(matched by CVE ID where present, or by a fuzzy title+date fallback).
Surfaces drift in three buckets:
- **Present in tracker, missing from dashboard** — needs publishing /
allocating upstream.
- **Present in dashboard, missing or stale in tracker** — tracker needs
to be brought up to date (advisory text, fixed-versions, credit
lines).
- **Both present, fields disagree** — diff the disagreeing fields and
propose a resolution direction (no auto-write — the security team
picks the winning source).

The step is **optional** because adopters outside ASF won't have this
substrate at all; the configuration should gate the step cleanly and
degrade to a no-op when the tool isn't configured.

## Out of scope

- **Auto-correction.** Surface drift, do not silently overwrite either
source. Security data is too high-stakes for that.
- **Write API on `dash.security.apache.org`.** Even if one becomes
available later, that's a separate skill — `security-cve-allocate`
would absorb the write side.
- **Cross-project reconciliation.** This is per-project — each adopter
reconciles against its own dashboard slice.

## Why this lives in `security-issue-sync` (not a new skill)

Sync is already the skill that reconciles one tracker entry against
multiple external sources; the dashboard is just one more source. Folding
it in keeps the security-team workflow as a single sync invocation rather
than splitting attention across two skills. The reconciliation step is
optional (gated by adopter manifest), so projects that don't have access
to the dashboard see no change in behavior.

## Acceptance criteria

- `tools/asf-dash-security` exists, has a `--help`-discoverable CLI, and
has end-to-end test coverage against a recorded fixture of the
dashboard response.
- `security-issue-sync` documentation describes the reconciliation step
and the project-manifest flag that enables it.
- When the flag is off (or the substrate tool is missing), the step is a
silent no-op.
- When the flag is on, the step surfaces drift in the three buckets above
and proposes a resolution direction the security team can confirm or
reject — same proposal-confirmation pattern as the rest of
`security-issue-sync`.