[feature]: Add diagnostics mode to capture proof failures and support artefacts

The goal is to introduce an extendable diagnostics feature that can aggregate troubleshooting data across tapd subsystems. A user should be able to zip the entire diagnostics directory and provide it to support or link it in a GitHub issue. In the first iteration we will focus on troubleshooting proof-validation failures during asset transfer.

Scope for first iteration

• Add --diagnostics-dir (and config field) to enable diagnostics. Diagnostics mode is disabled unless dir path is given.
• When in diagnostics mode:
  • On tapd start, create a new run directory under the diagnostics directory. Naming: ts<unix_ts>-pid<pid>.
  • After anchor tx broadcast during asset transfer, if generated output proofs fail validation, store those proof artefacts in the active diagnostics run directory for support.

Architecture notes

• Implement diagnostics as its own sub-service inside tapd that manages filesystem layout under the diagnostics directory.
• Other subsystems can hand artefacts to the diagnostics service, which decides placement and storage.
• Diagnostics runs non-blocking to avoid impacting normal tapd operation.

Future directions

• Dump tapd version and build metadata in the run directory.
• Optional trace logging directed to the run directory.
• diagnostics handles goroutine dumps and pprof capture under certain conditions.

Start at tapd startup and configuration handling, then trace asset-transfer proof validation after anchor transaction broadcast. Review how a diagnostics sub-service could own the run-directory layout and receive proof artefacts without blocking normal operation. Done means the diagnostics directory and run naming work when configured, proof failures are captured, and diagnostics remain disabled by default.