feat: route feedback to the server FlyBot Lead and complete the triage lifecycle #814

Written-by: HugoXK

Problem

A feedback or unexpected-error report currently stops at the maintainer mail. The server-deployed FlyBot's Fledge Lead never sees it, the reporter is never told whether it was a user problem, a duplicate, or a confirmed platform defect, and there is no path from “confirmed” to “fixed in version X” to “the updated service is live”. The Lead also has no safe way to write a conclusion back to GitHub without risking user data in a public issue.

Proposal

1. Route each report to the Fledge Lead

Support both deployment shapes, in this order:

1. FLEDGE_LEAD_REPO_ID=repo_... — a normal repo connected to Fledge; call
   instances.sendGuidance(repoId, 'lead', packet).
2. FLEDGE_LEAD_BRIDGE_URL + FLEDGE_LEAD_BRIDGE_TOKEN + FLEDGE_LEAD_SESSION_ID —
   an externally managed FlyBot; POST the same packet to the bridge's /dsh
send endpoint.

If neither is configured or the Lead is unreachable, keep the record and fall
back to the maintainer mail; the user's submission must still succeed.

The packet carries a short safe summary, the ref, the public-repo name, whether
the reporter consented to a public @mention, and a per-ref signed triage token.
It tells the Lead exactly how to read the full redacted record and write a
conclusion; raw stack/message stays behind the triage API, not in a public issue.

2. Triage API and lifecycle

• GET /api/feedback/:ref with the signed token: the redacted feedback/error
  record and its event history.
• POST /api/feedback/:ref/triage with the signed token:
  status, user_message, public_summary, issue_url, pr_url,
  fixed_version, duplicate_of.
• Statuses: user_error, duplicate, needs_info, confirmed,
  issue_opened, pr_opened, fixed, wontfix, plus system released.
• Each transition appends feedback_events and notifies the reporter in-app and
  by mail when there is a signed-in account and a user message. Anonymous error
  reports have no notification target; they still keep the audit trail.
• The Lead creates the public, sanitized GitHub issue itself and records its URL
  through the API. Fledge never publishes the raw message, stack, email or token.

3. Public issue, @mention and consent

• Feedback form: optional “I agree Fledge may @ my GitHub account in a sanitized
  public issue citing this feedback.”
• Error report: the required failure-data consent stays; an additional optional
  public @mention consent appears only when signed in.
• With consent, the Lead may @ the reporter, thank them and cite the ref in a
  sanitized issue. Without consent, the Lead can still triage privately and the
  reporter still receives in-app/mail updates, but no public mention is made.

4. Fixed and released notifications

• The Lead records pr_url and fixed_version on a confirmed fix.
• When the running VERSION is at or above fixed_version, Fledge notifies the
  reporter once: “fixed in vX” with the issue and PR links.
• After the platform service is updated, the same scan marks the record
  released and sends the final “now live in vX” notification once. A re-deploy
  of the same version does not send it twice.
• SemVer comparison reuses src/releases/release.ts, not a second parser.

5. Data and privacy

New feedback_triage and feedback_events tables (additive). The triage row
holds status, consent flags, issue/PR URLs, fixed/released versions, the
user-facing message, public summary and last-notified state. Raw feedback/error
data stays in the existing tables; the signed triage token is per ref and is
delivered only through the private Lead channel.

Scope and tier

Config, src/db.ts, src/app.ts, src/feedback/, src/email/templates.ts,
src/views/, tests, docs, .env.example, changelog. T3.

Verification

• A repo-mode send reaches instances.sendGuidance(repoId, 'lead', …); a
  bridge-mode send reaches /dsh with the configured session and token.
• The triage API rejects a bad token and an invalid status; a valid transition
  records the event, updates the row and notifies the signed-in reporter once.
• fixed_version at or below VERSION sends the fixed notification and then the
  released notification exactly once.
• Public-issue consent is stored and appears in the packet; no raw message,
  stack, email or token is placed in a public issue by Fledge.
• npm run check passes.