[Story]: PM Buddy — run a managed project from the buddy

[LinseCed]

User Story

As a PM, I want to switch the buddy into a "My team" mode for a project I manage and both ask about
and act on that project — who is stuck, open escalations, starter work waiting for review — so I can
run the project from one conversation instead of six pages. Nothing changes until I confirm it.

Context & Motivation

• Type: Functional (agent actions on the PM surface)
• Parent epic: 05 EPIC - Agent Orchestration & Workflow Actions #54 (05 EPIC – Agent Orchestration & Workflow Actions)
• Teams: team:backend, team:ai, team:frontend
• Concept: pm-buddy-concept.md
• Builds on: the buddy's propose → confirm actions (BuddyActionType), the per-message
  capabilities mode (backend [Feature]: Feedback to Onboarding as User #217), ProjectAuthorization.canManageProject.

The critical piece of this story: today every buddy tool reads the caller only
(BuddyToolExecutor.kt:25), and most PM REST endpoints check the PM role, not "manager of this
project". Team mode must enforce the manager check itself, on every turn and again on every confirm —
it cannot inherit it from the endpoints.

In Scope

• "My onboarding / My team" switch, scoped to the selected project, visible only to its manager
• Team conversation per (user, project), separate from the hire's buddy
• Server-stored action proposals, confirmed by id, re-validated on confirm
• Tools mounted by area (open_area) instead of all at once
• Team reads: attention list, one member's progress
• Actions: answer / dismiss escalations, edit canonical answers, refresh FAQ and knowledge gaps,
  review / reject / promote starter work, Task 0 eligibility

Acceptance Criteria

• A project's manager can switch to team mode; anyone else never sees the switch, and a forged
  request for a project they do not manage is refused
• Team tools and actions are only mounted in team mode, and only for the selected project
• Every action is a proposal until confirmed; confirm re-checks authorization and target state
• A PM can answer an escalation from the buddy with an answer drafted from the docs
• A PM can review, reject and promote starter work whose source belongs to their project
• Starter work with no resolvable project is not actionable in team mode
• Global catalogs (skills, project roles, global arrival defaults, repository / Jira config) are
  never mounted in team mode
• The hire's buddy behaves exactly as before

Technical Notes

• ~70 PM write operations exist; this story covers the foundation plus knowledge and starter work.
  Team & roles, arrival steps, content and sources are follow-up stories on the same foundation.
• Secrets, file uploads and long streamed generations are hand-offs to their page, never done in chat.

Sub-Tasks (by team)

• Backend — team mode foundation: mode, per-(user, project) conversation, manager check, per-hop mounting, stored proposals, team reads (A team mode for the buddy: manager-scoped tools and stored action proposals sprintstart-backend#215)
• Backend — team-mode actions for escalations and starter work (Team-mode actions: escalations and starter work sprintstart-backend#225)
• AI — persona told the mode: capabilities off and team mode (Tell the buddy persona which mode it is in: capabilities off and team mode sprintstart-ai#193)
• Frontend — mode switch and stored-proposal confirm card (My onboarding / My team: mode switch and stored-proposal confirm card sprintstart-frontend#218)
• AI — team greeting when a manager opens the buddy in team mode (Team greeting when a manager opens the buddy in team mode sprintstart-ai#194)