fix(frontend): stop the MCP Usage tab calling an unknown owner "Personal"

[archestra-task-envs]

The bug

On an MCP server's Usage tab, the Owner column is inconsistent: some
personal agents are attributed to an email address, while others — including
agents belonging to the person looking at the page — just say "Personal". So
"Personal" cannot be read as "this one is yours", and two rows for the same
owner can disagree.

mcp-server-usage-tab.tsx rendered the cell like this:

const owner = agentOwnerLabel(agent); // agent.ownerEmail, for personal agents
...
{owner ? <span>{owner}</span> : <span>{scopeLabel(agent.scope)}</span>}

agentOwnerLabel returns ownerEmail for a personal agent and null
otherwise, so the fallback is doing two unrelated jobs at once:

• for a team- or org-scoped agent it prints "Team" / "Organization",
  which is right — such an agent belongs to the team or the organization, so
  the scope is the owner;
• for a personal agent with no email it prints "Personal", which answers a
  different question than the column asks. It is a visibility scope wearing the
  clothes of an owner, and it reads as "mine".

Why the email was missing

ownerEmail comes from a LEFT JOIN onto the agent's author
(AgentToolModel.getAssignedAgentDetailsForMcpServers and
AgentModel.getAutoModeAgentDetailsByOrganizations), and agents.author_id is
declared ON DELETE SET NULL.

The user row is genuinely deleted, and by an ordinary flow: removing someone
from an organization deletes their account outright once it was their last
membership —

// routes/auth.ts, POST /api/auth/organization/remove-member
const hasRemainingMemberships = await MemberModel.hasAnyMembership(userId);
if (!hasRemainingMemberships) {
  await UserModel.delete(userId);
}

So every agent a departing colleague authored kept its row and lost its author,
with no name or email left anywhere to recover. Those are exactly the rows that
came out labelled "Personal", sitting in the same table as rows that named a
real person.

The Usage tab was also the only surface that took this fallback. The two other
consumers of agentOwnerLabel (the registry card's "used by" tooltip and the
uninstall dialog) append the owner to an agent's name and render nothing when
there isn't one, which was already correct.

The fix

1. Carry the owner's id, not just their email

McpServerAgentUsageSchema gains ownerId (agents.author_id), selected in
both queries that build the shape. Deciding "is this row mine" by matching the
session's email against a display string is the wrong instrument, and that
string is null on precisely the rows that most need telling apart.

2. Say the author is gone, without storing anything

For a personal agent, author_id IS NULL already means "the author's account
was deleted": every create path stamps an author, and both routes that could
make an existing agent personal (PUT /api/agents/:id and the bulk visibility
route) refuse to do so without one. So there is no other way into that state,
and the cell can derive "Deleted user" from the shape of the data.

An earlier revision of this PR added an agents.deleted_author_email snapshot
column so the row could name which person. That was the wrong shape and it is
gone. Sixteen tables lose a user identity when an account is deleted —
audit_log.actor_id among them — so a column on agents fixes one instance and
invites the next; it also introduced a bug of its own, a server-owned field that
turned out to be writable through the public agent APIs.

Naming the person requires the identity to survive, which means not destroying
it: soft-deleting users instead of hard-deleting them, so all sixteen tables
keep their authorship and no table needs a column. That is a change to
UserModel.delete and to the auth read paths — account and session cascade
today, user.email is hard-unique, and better-auth owns every sign-in query —
so it deserves its own PR rather than riding along with a UI fix.

3. One explicit decision instead of a fallback

describeAgentOwner (lib/agent-owner-label.ts) replaces the ternary with a
discriminated result the cell renders branch by branch:

row	Owner column
your own personal agent	You (the email stays in the title)
someone else's personal agent	their email
personal agent whose author's account was deleted	Deleted user
team- / org-scoped agent	Team / Organization

The personal scope label no longer appears in that column at all, so nothing in
it can be misread as an owner. "Deleted user" stays in front of the address
deliberately: a bare address invites the reader to go and ask a colleague who
has left. Unknown is now only reachable for agents orphaned before the snapshot
existed — a set that only shrinks.

agentOwnerLabel remains, documented as the short qualifier form, for the two
name-suffix surfaces above.

Notes

• Pinned in mcp-server-usage-tab.test.tsx: the viewer's own agent renders
  "You" and never "Personal", and an authorless personal agent renders "Deleted
  user" — not "Personal", not "You". Those are the readings the bug conflated,
  and they are decided entirely by props, so an e2e would add fixtures without
  testing anything more.
• Verified against the running dev stack: seeded a scene covering every branch,
  then removed two members through the real deletion path and watched their
  rows read "Deleted user". Checked at desktop and narrow widths, no new
  console errors.
• Follow-up worth filing: users are hard-deleted, and sixteen tables carry
  a SET NULL FK to them, so every account removal silently erases authorship
  across the platform — including audit_log.actor_id, which loses its actor.
  Soft-deleting users fixes all of them at once and removes any need for
  per-table snapshots. It also carries a retention question of its own, since
  keeping the row keeps the email.
• The retained identity is now available to any surface with the same problem —
  the Agents list's "Accessible to" column still renders - for a deleted
  author — but this PR changes only the column that was reported.
• I could not read the originating discussion thread from this environment (the
  MCP gateway rejected this session's token), so this works from the
  second-hand summary of it.

---