Persist failed outbound delivery attempts in traces #1257

Background

#1205 aligns federation logs with their operation spans for #1030. Failed outbound deliveries still have no TraceActivityRecord: sendActivityInternal() emits activitypub.activity.sent only after a successful response, and FedifySpanExporter extracts records from sent/received events. A failed delivery therefore has a span and error logs, but no activity record to display beside those logs in #902.

This is an existing limitation, separate from the logging-context fix. This issue tracks the federation instrumentation and exporter changes needed before #902 can show failed outbound attempts with their related logs.

Scope

Persist failed outbound delivery attempts with enough typed data to identify the activity, destination inbox, and delivery outcome. Keep activitypub.activity.sent reserved for successful delivery and preserve the existing trace hierarchy.

Before implementation, settle how failure events or span attributes produce records, how success/failure is represented in TraceActivityRecord, and how retries affect record grouping and TraceSummary.activityCount. Records should retain the delivery attempt's own traceId/spanId so its logs can be matched directly. Multiple attempts for the same activity and inbox must remain distinguishable.

Account for trace-list visibility when every attempt fails and for compatibility with existing successful outbound records. Define how worker-level retry, abandonment, and circuit-breaker logs relate to delivery records, including cases that never enter sendActivity(). Those logs should retain their worker span IDs.

#902 owns log spanId persistence and debugger rendering, including success/failure labels, grouping attempts, and showing logs without a matching activity record. This issue supplies the records and typed outcome data that rendering needs.

Validation

• Exercise a failed delivery inside a real queue worker, export its span through FedifySpanExporter, and verify that the persisted failure record and emitted delivery error log have the same traceId/spanId.
• Cover HTTP error responses and transport failures, then a retry sequence that fails before succeeding. Verify distinct attempt records, correct outcomes, and consistent trace summaries.
• Verify that an always-failing delivery is discoverable through the exporter's recent-trace listing and that successful delivery records remain compatible.
• Check that worker retry/abandonment logs retain their worker IDs and are not attributed to a delivery attempt that never ran.

Update the public telemetry documentation and add a changelog fragment for the resulting behavior. Run the affected package suites on Deno, Node.js, and Bun. The debugger rendering checks remain in #902.