[feature]: bugreport pipeline: tapd error -> diagnostics bundle -> upload

[ffranr]

Background and dependency

Builds on diagnostics mode: #1867

This issue proposes the next step: an automated bug report pipeline that can package whatever diagnostics artefacts were collected for a given failure.

---

Goal

In diagnostics mode, tapd should be able to automatically generate a bug report bundle when it encounters qualifying errors, and optionally submit it to a Lightning Labs server.

Intended end-to-end pipeline:

1. tapd error occurs
2. diagnostics artefacts are collected into a bug report bundle
3. bundle is optionally uploaded
4. server-side automation (LLM-assisted) analyzes the report and creates a GitHub issue
5. optionally, subsequent automation attempts a candidate fix PR

This issue is about the concept and product shape, not implementation.

---

What a bug report contains

A bug report should be a single portable bundle (zip or tarball) that a user can:

• attach to a support ticket
• link in a GitHub issue
• submit automatically when enabled

The bundle should include a curated set of troubleshooting data, for example:

• tapd version and build metadata (commit, build tags, dirty state)
• OS, architecture, Go version
• relevant log material
• diagnostics artefacts captured for the failure (initially proof-related artefacts, but designed to generalize)
• goroutine dump (where applicable)
• structured error context that helps reproduce or classify the failure

---

Log size management (must-have)

Logs can be extremely large (multi-GB), so bug reports must avoid attaching full logs by default.

Proposed approach: include log excerpts around error events, rather than complete files. Examples:

• N lines before and after lines containing ERROR (or structured error level)
• time-window based slices (for example, from t_error - 5m to t_error + 5m)
• cap total log bytes per report, record truncation in a small manifest

This keeps reports small while preserving the most relevant context.

---

Consent, privacy, and trust

Auto-submission must be explicit opt-in and easy to disable.

Bug reports should be designed to avoid secrets by default, and to minimize identifying data unless the user opts in. The bundle should record what it contains (manifest) so users and support can reason about content.

---

Open questions

• What error classes should trigger report generation (v1 might start with proof-validation failures, but should expand to other high-value failure modes)?
• What is the default user experience: generate-only by default, or allow immediate upload with explicit opt-in?
• What redaction policy is acceptable for “safe by default” reports (node pubkey, txids, channel IDs, IPs, filesystem paths)?
• What maximum bundle size is acceptable for reliable upload and support handling?