[FEATURE] Routines: create runs as shared (Team) sessions by default

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet (the closest, #61640, is framed around CLI claude --resume / plan approval — see Additional Context)
• [x] This is a single feature request (not multiple features)

Problem Statement

Routines run autonomously on the web under a single owner's account and open PRs under the owner's GitHub identity. Each run's session is created Private, and sharing is a manual, per-run, after-the-fact UI action. The existing "Team" share scope is view-only.

As a result, the routine owner is a bottleneck: when review comments land on a routine-created PR, only the owner can act inside the session that holds the full run context (why each change was made, the investigation, the tool calls). Teammates can view the run but cannot pick it up. For a team that relies on routines to do real work, every routine becomes single-owner-dependent.

Proposed Solution

Add a per-routine (ideally also per-workspace) setting to create each run's session as a shared (Team) session by default, gated on the organization's existing repo access:

• A toggle in routine settings: "Make runs shared with my team" → new runs are created with Team visibility, with no manual per-run share step.
• The shared session should be continuable / editable by other org members with repo write access, not view-only (the natural complement to the routine default; overlaps with #61640).
• Side effects after a teammate continues the run execute under that teammate's connected identity — expected and acceptable.

Alternative Solutions

• Manually open each run and switch it to Team share — clunky, per-run, and still view-only so teammates can't act.
• Have teammates start a fresh session on the PR branch — loses the run's accumulated context and forces re-ramp on every review cycle.
• Rely only on the PR + Slack notification for visibility — gives awareness of outputs, but not the ability to continue the reasoning the routine already did.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

1. We run a daily "meeting-ingest" routine and a weekly "sentry-remediation" routine on the web; each opens a PR under the owner's GitHub identity.
2. A reviewer leaves comments on a routine-created PR.
3. Today only the routine owner can continue that run's session to address them; teammates can view it (Team share) but not act, so they start a fresh session and lose the run's context.
4. With this feature, the routine creates runs as shared Team sessions by default, so any teammate with repo write access opens the same run, continues it, and pushes fixes addressing the review — no owner bottleneck, no context loss.

Additional Context

• Related: #61640 (allow shared sessions to be resumed by another user — CLI --resume / plan-approval framed; this request is the web / Routines "created-shared-by-default" complement). Also related: #61537 (multi-player sessions), #61849 (cross-device session continuity).
• Observed in the web research preview: the "Share session" dialog offers Private / Team, where Team = "everyone in \<org\> with repo access + the link can view" (view-only). There is no per-routine or default visibility setting today.
• Suggested area label: area:routines.