refactor(jira): remove the code-owned Jira chat agent

[viktormarinho]

What is this contribution about?

Removes the "Jira" agent added in #7747. It was a virtual MCP over the org's self connection with the JIRA_* tools selected, created automatically for every org with an enabled Jira integration, and its instructions and tool list were pinned from code at run time. That made it impossible to adapt per org (edits to its instructions were silently replaced), and nothing about it needs special code: an org that wants a Jira agent can build an ordinary one over the same JIRA_* tools.

• Deletes apps/api/src/jira/chat-agent.ts and its tests.
• JIRA_INTEGRATION_UPSERT / JIRA_INTEGRATION_DELETE no longer create or remove an agent.
• resolveEffectiveStudioPackVirtualMcp no longer overrides that agent's instructions and tools.
• Migration 231 becomes a no-op: databases have already run it, and new ones should not get the agent.
• Migration 233 deletes the agents 231 created (studio-jira_<orgId>), the same way VirtualMCPStorage.delete does: threads, aggregations, then the VIRTUAL connection.

Kept from #7747: the JIRA_* tools still work outside a run (named issueKey, still confined to the connected board; JIRA_ISSUE_CREATE takes the project from the board).

How did you verify your code works?

• New 233-remove-jira-chat-agent.integration.test.ts (real Postgres): seeds a studio-jira_ agent with a thread and an aggregation next to an unrelated agent, thread and aggregation; runs up twice; only the Jira agent's rows are gone.
• bun run migrate on an empty local Postgres, then bun test migrations/233-remove-jira-chat-agent.integration.test.ts migrations/index.test.ts: 3 pass.
• bun test src/tools/jira src/tools/virtual src/jira: 246 pass.
• bun run check: passes. bun run verify: 10,287 pass, 0 fail.
• Before writing 233, counted what references these agents in production: 2 agents, 2 aggregations, 0 threads, nothing in organization_settings.

How to Test

1. On a database where 231 ran, run migrations: the studio-jira_* connections and their aggregations are gone.
2. Save or delete a Jira integration: no agent is created or removed.
3. Call JIRA_ISSUE_GET with an issueKey on /mcp/self outside a run: it still works.

Migration Notes

Migration 233 deletes data: every connection whose id starts with studio-jira_ (only migration 231 or the removed sync created those), with its aggregations and threads. In production that is 2 agents and 0 threads today.

Review Checklist

• PR title is clear and descriptive
• Changes are tested and working
• Documentation is updated (if needed)
• No breaking changes

---

Summary by cubic

Removes the code-owned "Jira" chat agent and the code that created and kept it in sync, because its instructions and tool list were pinned from code at run time and could not be adapted per org. An org that wants a Jira agent can now build an ordinary one over the same JIRA_* tools, which keep working on /mcp/self outside a run.

• JIRA_INTEGRATION_UPSERT / JIRA_INTEGRATION_DELETE no longer create or remove the agent, and resolveEffectiveStudioPackVirtualMcp no longer overrides it.
• Migration 231 is now a no-op since it has already run; migration 233 deletes the studio-jira_<orgId> agents it created, along with their threads and aggregations.
• Migration 233 runs the deletes in the same order as VirtualMCPStorage.delete: threads, aggregations, then the VIRTUAL connection.

^{Written for commit b3d3057. Summary will update on new commits.}