bug(agents): orchestrator_list publishes every peer as context/repository/metadata unknown on 4.2.0 although #1701 shipped #2305

Before submitting

• I searched open and closed issues and did not find a report of this problem.
• I reviewed this report and removed credentials, tokens, private paths, hostnames, and other sensitive data.

Problem

With gentle-pi 4.2.0, orchestrator_list returns only opaque session IDs. Every advertised peer renders as context: unknown · repository: unknown · metadata: unknown · recorded catalog: unknown, and orchestrator_consult with kind: metadata answers status: unavailable, unknowns: ["publication-unknown-or-stale"] for each of them, including peers that are live and whose host workspace is recorded on disk.

#1701 (closed COMPLETED on 2026-10-04 via PR #1714, #1715 and #1720) and #1996 (closed via PR #1998) ship exactly this publication. PR #1720 states the recorded host root is published without requiring a subject declaration. All of these merged before the 4.2.0 release, so the installed package should carry them, yet nothing is published.

Practical impact: an orchestrator that needs to message a peer working in a sibling repository cannot recognize it. In my case the session had to be located by hand by matching the newest JSONL under ~/.pi/agent/sessions/<cwd-slug>/, and the first message went to a stale peer (the #1443 case) because the picker from #1308 offered seven indistinguishable IDs.

Steps to reproduce

1. Linux, gentle-pi 4.2.0, Pi 1.3.0, default profile. Start two interactive sessions in two different Git repositories (I had three live plus stale advertisements, seven peers total).
2. In one of them call orchestrator_list with no arguments.
3. Call orchestrator_consult with recipient_session_id set to each listed ID and no kind (metadata).
4. Optionally call orchestrator_list with filter: {"text": "<repo name>"}.

Observed:

- 01a141b0-8f28-721e-b281-a341d8b241c7 · context: unknown · repository: unknown · metadata: unknown
  recorded catalog: unknown

(same for all seven IDs; 01a141b0-8f28… is a live session whose JSONL sits under the sibling repository's session directory)

{"schema":"gentle-agents.consultation/v1","kind":"metadata","status":"unavailable",
 "source":"published_snapshot","ownerReply":false,"authority":"none",
 "freshness":"unknown","unknowns":["publication-unknown-or-stale"],
 "omissions":["private-context","owner-decision","reachability","exclusive-writer-ownership"]}

The filtered list returns "matches":[] with "unknownContext":7,"catalogUnknown":7.

Neither session had declared a subject via orchestrator_session_id; per PR #1720 the repository scope should still be published.

Expected and actual behavior

Expected: each live peer shows its recorded repository root (or clone hash) and, when declared, its alias, as described in #1701 / PR #1714 and #1720. orchestrator_consult metadata returns the published snapshot.

Actual: every peer is unknown on every field and metadata consultation is unavailable. Discovery degrades to the legacy schema-1 activity header.

Hypothesis, not verified: PR #1714 binds the published metadata to the selected transport activation and presence generation. If the transport does not arm at startup, discovery silently falls back to the legacy header. #2166 reports the transport never arming on Windows with the failure discarded; this may be the Linux face of the same defect, or a packaging gap between what the PRs verified with the SDK and the published 4.2.0 bundle.

gentle-pi version

4.2.0

Pi version

1.3.0

Operating system

Linux

Additional context

Related: #1701, #1996, #2166 (transport never arms), #1443 (stale peers advertised), #1308 (recipient picker), #2124 (hidden transport errors).