11/12 Add co-op deploy follow-up support

[tomer-stripe]

Part 11 of the clean co-op stack targeting coop.

This PR adds deploy-oriented follow-up support for completed co-op sessions without introducing deployment as a normal integration blueprint.

Changes:

• Adds deploy and deploy-update next-action suggestions after a session completes.
• Adds internal compiled guided actions for deploy follow-ups. These create normal parented co-op sessions, so the TUI can show step-by-step deploy progress in the left rail, but they are not embedded blueprint JSON, are not returned by ListBlueprints, and are not started through stripe coop run.
• Keeps the generic guided-action-to-session machinery in pkg/coop, while deploy-specific guided action definitions live in pkg/coop/followups.
• Adds stripe coop agent start-followup for agents to create those guided follow-up sessions from a completed parent session.
• Separates deploy-update from deploy: existing deployment infrastructure gets a guided flow that pushes the integration changes to the detected target.
• Updates the TUI so deploy choices wait for the guided follow-up session; add-integration still waits for a new integration session.
• Adds/updates tests for guided action definitions, command creation, next-action responses, TUI waiting behavior, and parent-session routing.

Review notes:

• The earlier deploy-stripe-projects blueprint was removed in response to review feedback. Deploy is modeled as an internal follow-up action with session steps, not as blueprint source of truth.
• The deploy guided action tells the agent to use Stripe Projects plugin detection and commands as the deployment source of truth.
• The deploy-update guided action tells the agent to use the existing detected provider path.
• The deploy guidance tells the agent not to supplement or modify co-op blueprints as deployment source of truth and not to print secret key material.

[kwu-stripe]

I'm not sure if representing the Stripe Projects flow as a blueprint makes the most sense. This feels more like a deployment follow-up that we use after each integration than an integration itself. Would it be better modeled as a deploy action / prompt that asks the agent to use the Projects plugin's own detection and commands?

[tomer-stripe]

so I kind of agree with you that this doesn't make 100% sense as a blueprint-proper. It doesn't map perfectly to the conceptual backing we've built around blueprints. The step-by-step flow of a blueprint does kind of fit here tough in guiding the user through a bunch of steps to help them get deployed.

I don't feel too strongly here, I'm fine not merging this one for now and addressing this separately as a one-off or adhoc feature.