Upstream adoption: native remote-agent references and mixed teams

[100yenadmin]

Parent: #1
Related: #7, #40, #43
Upstream dependency: block#2333

Observable outcome

Remote company agents use Buzz's native durable public-agent reference across
Agents, profiles, DMs, mentions, channel membership, presence, huddles, and
teams. Hive does not introduce a parallel VM-agent data model.

Architecture correction

The prior issue proposed a Hive-side normalization and team migration.
Current upstream direction already separates generic ACP runtimes from remote
agent identities and has an open native shared-agent mention fix in
block#2333.

This issue is therefore a post-canary upstream-adoption gate:

• prefer native upstream agent references and team membership;
• keep any temporary Hive compatibility patch generic and deletion-ready;
• do not fabricate a local persona, private key, or managed runtime for a
  company VM identity;
• do not migrate native team storage until upstream defines the durable remote
  agent reference accepted by teams.

Acceptance

• One registered public agent identity renders once across native surfaces.
• Secondary clients discover and mention it without local runtime ownership.
• Runtime controls remain capability-gated and never imply local ownership.
• Mixed local/remote team behavior is implemented upstream or through an
  accepted generic upstream seam, not a Hive-only team schema.
• Adding/removing a remote identity from a team never starts, stops,
  deletes, rotates, or configures Hermes.
• Existing native local personas and teams load without loss.
• Cross-company identities and memberships remain undiscoverable.
• Exact-head focused tests, canonical CI, semantic review, and a two-client
  installed proof pass before this becomes a release dependency.

Non-goals

Hive-side Hermes provisioning, a Supabase room/team registry, VM administration,
content retrieval, employee-file access, or broad current-release work.

Sequencing

Deferred until the v0.5.2 Internal Canary is stable. Recheck block#2333 and
current upstream team support before implementation. Do not carry the old broad
Hive model migration into the release candidate.

Stop conditions

Stop on duplicate identity, local-key fabrication, cross-tenant discovery,
Hermes authority leakage, or any requirement to replace native Buzz
collaboration/team protocols.

Proof boundary

Planning and source tests do not prove team parity. Installed two-client
local/remote-team behavior is required. This issue does not block the v0.5.2
Internal Canary unless that exact supported path is explicitly added to its
acceptance gate.

[100yenadmin]

Accepted follow-up from #39 semantic review — 2026-07-28

While closing #39, the independent exact-head review found one non-blocking P3 that belongs to this normalization surface:

• Finding: mergeCompanyAgentSearchResults can omit a catalog-only company VM agent when the native relay result page is already full.
• Evidence: a bounded probe against the Bug: present registered VM agents through native Hive identity surfaces #39 range returned { "length": 8, "hasCompany": false } for a full relay page.
• Why this belongs here: it is an agent-reference/search ranking and normalization edge across native relay results and Electric company catalog results. It does not expose a raw public key, does not broaden tenant discovery, and does not block Bug: present registered VM agents through native Hive identity surfaces #39’s installed presentation fix.
• Requested disposition in Upstream adoption: native remote-agent references and mixed teams #62: when normalizing registered VM agents into native agent references, rank or promote matching company-catalog identities before applying the result limit, and add a full-relay-page catalog-only test.

Boundary: this is a Milestone 2 follow-up only. Do not start #62 until the Internal Canary gate is stable.