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

[potiuk]

Problem

security-issue-sync reconciles a single tracker entry against its GitHub
discussion, the inbound <security-list> thread, and any <upstream> 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.

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.

[potiuk]

Status check against main — still valid and unimplemented. One design note, since the framework grew a relevant mechanism after this was filed.

Neither piece exists: there is no tools/asf-dash-security, and security-issue-sync has no dashboard reconciliation step. The problem statement still holds — tracker-versus-dashboard drift is caught only by manual cross-referencing.

The new consideration. organizations/ASF/organization.md landed after this issue and is now where ASF-specific backends are bound to generic capability contracts:

the shipping ASF backends are tools/cve-tool-vulnogram/, tools/ponymail/, tools/apache-projects/, and tools/gmail/asf-relay.md

So the tool should be registered there alongside the others rather than only referenced from the skill.

Worth deciding at design time, not after: whether this ships as a bare ASF-named tool or behind a generic contract with the ASF dashboard as its first adapter. Both shapes have precedent in-tree — tools/apache-projects/ is ASF-named directly, while tools/cve-tool/ is a contract with cve-tool-vulnogram beneath it. The contract shape costs more up front and buys two things: a non-ASF adopter with their own advisory inventory (a CNA's internal tracker, a foundation-level dashboard elsewhere) can plug in, and the capability appears in the vendor-neutrality measurement rather than sitting outside it.

Given the project publishes that score and has spent real effort removing single-vendor assumptions (#1055, #997, #998), I would lean toward the contract shape — but it is a judgement call for whoever picks this up, and the reconciliation logic in security-issue-sync is the same either way.

No action needed on the issue text; recording the binding point so the implementation does not have to rediscover it.