Enh: Surface pinned Agents in the left sidenav

[kimstate]

I believe this was a legacy feature... unless there is another way to order assistants, the request is to permit pinning/unpinning of assistants; pinned assistants display in left nav for quick access

[philmerrell]

Retitled from "Enh: Pin/unpin assistants" and restated against the Agent noun. Two notes on why, and what is actually left.

Pinning shipped; the surface this issue asked for did not

The request has two halves. The Agent Marketplace epic delivered the first and missed the second.

Built — Marketplace phases 5 and 6 (#736, #737, both merged to develop; not yet in a prod release):

• POST /agents/{id}/pin, DELETE /agents/{id}/pin, GET /agents/pins — backend/src/apis/app_api/agent_designer/routes.py:307,620,639
• Unpin writes a dismissal tombstone, so a role-seeded pin the user removed does not resurrect on the next resolution; pin and dismiss are deliberately one toggle
• Admins seed default pins per AppRole (GET/PUT /admin/roles/{roleId}/agent-pins), resolved live per request as (⋃ role pins) − dismissed ∪ own pins — no fan-out, no materialized copy per member

Not built — "pinned display in left nav for quick access," which is the literal ask here. Pins surface in four places today, none of them the sidenav:

Surface	Location
"Your pinned agents" strip	agents/discover/discover.page.ts:145-172
Dedicated Pinned tab	/agents/pinned
"Add"/"Added" button	agents/detail/agent-detail.page.ts:161-178
@-mention menu (group: 'pinned')	agents/services/agent-mention.service.ts:39

components/sidenav/sidenav.ts never injects AgentPinService. The nav is New Session → Assistants → Agents → session list → user dropdown, and nothing else.

This reads as an oversight rather than a deliberate deferral: docs/specs/agent-marketplace.md promises the sidebar three times — "a student's first session already has the Canvas student agent in the sidebar" (:19), "a role's members start with a useful sidebar instead of an empty one" (:200) — and specs a 28px icon size "(sidebar, @ menu)" (:149) that no sidenav code renders. The backend docstring in apis/shared/assistants/role_pins.py repeats the same promise. So the store, the pin state, the role seeding and the icon asset all exist for a destination that was never wired up.

Why the noun changed, and why there is nothing to migrate

Legacy Assistants have no pin, favorite, star, or manual ordering — the list is a fixed server-side created_at descending sort (apis/app_api/assistants/routes.py:233) with no user-controllable order field. So there is no existing assistant-pinning behavior to carry forward; this becomes an Agents feature outright, consistent with #746 (Assistant deprecation, Designer Phase 5).

⚠️ One naming trap for whoever picks this up: backend/src/apis/shared/assistants/role_pins.py sits under an assistants/ package but is entirely Agent role pins (AGENT_PIN#{agent_id}). That is legacy packaging, not a legacy-assistant feature — don't read it as prior art for pinning Assistants.

Remaining scope

A pinned-Agents section in components/sidenav/. The data layer is already built, already session-cached, and already loaded by other surfaces, so the component only needs to inject AgentPinService and render — plus the locked affordance (role-seeded pins the user cannot dismiss) and a cap with an overflow link to /agents/pinned.

Sequencing: this should follow #746. The sidenav still ships both "Assistants" and "Agents" as separate entries; adding a pinned-Agents section before the nouns are unified means designing it against a nav that is about to change shape, and building it twice.