fix(orchestration): don't abort first agent link on 404 contact status

[CodeGhost21]

Problem

Linking a new agent for the first time is impossible from the UI. In Orchestration → Discover → "Link a new agent", pasting any valid agent ID and clicking Link fails with:

HTTP 404: /contacts/<id>/status: not found

This happens for every agent you have not already linked — i.e. the normal first-contact case.

Root cause

link_session (src/openhuman/agent_orchestration/pairing.rs) pre-checks the relationship via contact_status, which calls GET /contacts/{id}/status. The backend returns 404 when there is no contact relationship yet. contact_status ran that response through map_err(map_err)?, turning the 404 into a hard error that propagated out of link_session before it ever reached the POST /contacts/{id} that sends the request.

Verified against staging: GET /contacts/{id}/status returns 404 pre-link and flips to 200 pending only after a request is sent — so the 404 is expected state, not a failure.

Fix

Treat a 404 from the status pre-check as "none" (no relationship yet) so link_session proceeds to send the request. Other HTTP/transport errors still propagate unchanged. tinyplace::Error::status() returns Option<u16>, so the 404 is matched precisely rather than by string-sniffing.

match client.http().get_agent_auth::<Value>(&contact_path(agent_id, Some("status")), &[]).await {
    Ok(remote) => Ok(remote_status(&remote).unwrap_or_else(|| "none".to_string())),
    Err(e) if e.status() == Some(404) => Ok("none".to_string()), // no relationship yet
    Err(e) => Err(map_err(e)),
}

Testing

• Reproduced the 404 on main in the desktop app against staging.
• Confirmed the contact lifecycle on staging out-of-band (request → pending → accept → accepted), proving the backend path is healthy and the 404 is purely the pre-check.
• With the fix built into the app, the Link action sends the request instead of erroring.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes
  • Improved contact linking by treating contacts without an existing relationship as having a neutral status.
  • Prevented unnecessary errors when no relationship status is available.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: dc2a84d1-56db-4c69-b490-52629f354c22

📥 Commits

Reviewing files that changed from the base of the PR and between f5b77ed and e5eb0f6.

📒 Files selected for processing (1)

• src/openhuman/agent_orchestration/pairing.rs

---

📝 Walkthrough

Walkthrough

Changes

Contact status lookup

Layer / File(s)	Summary
Handle missing relationships src/openhuman/agent_orchestration/pairing.rs	contact_status logs 404 responses and returns "none", while preserving remote status mapping and propagation of other errors.

Estimated code review effort: 2 (Simple) | ~10 minutes

Poem

I’m a bunny hopping light,
A missing link is now alright.
Four-oh-four? No need to fear—
“None” lets pairing persevere!
Debug crumbs sparkle in the night.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the 404 contact-status fix that prevents first agent linking from aborting.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

_{Comment @coderabbitai help to get the list of available commands.}