Interoperability smoke tests: phase 2 & 3

[sij411]

Background

Issue #481 established an automated E2E interoperability smoke test suite
to systematically verify Fedify's federation logic against live ActivityPub
implementations — filling the gap between unit tests and manual testing,
similar to Node.js's CITGM.

The work introduced:

• A GitHub Actions workflow that spins up target ActivityPub servers and a
  Fedify test harness via Docker Compose
• A minimal Fedify test harness app (under test/smoke-harness/) with
  backdoor APIs (/_test/*) for the CI orchestrator
• A Deno orchestrator script that drives E2E scenarios by communicating
  with both the harness and the target server's API

The infrastructure introduced in phase 1 consists of:

• A shared Fedify test harness app (test/smoke/harness/) with backdoor
  APIs (/_test/*) that let the CI orchestrator drive Fedify-side actions
• A shared Deno orchestrator (test/smoke/orchestrator.ts) that runs E2E
  scenarios against both the harness and the target server's API
• Per-target directories (test/smoke/{target}/) each containing a Docker
  Compose stack, Caddy TLS proxies, a provisioning script, and a GitHub
  Actions workflow
• Self-signed TLS certificates per target, required because several
  ActivityPub servers enforce HTTPS for all federation traffic

Phase 1 (core microblogging) has been completed and merged, covering
Mastodon and Sharkey (Misskey fork).

Goal

This issue tracks the remaining phases of the phased rollout originally
planned in #481.

Phase 2 — Major stacks & types:

• Akkoma/Pleroma (Elixir-based)
• Pixelfed (Media-focused, Image/Video objects)

Phase 3 — Service diversity:

• PeerTube (Video / Group actor for channels)
• Lemmy / Kbin (Community / Group interaction)
• WriteFreely (Article objects)

Each target implementation will be tracked in its own sub-issue, where the
specific Docker setup, test scenarios, and acceptance criteria will be
defined.