RFC: conversational Slack-to-Jira intake and autonomous implementation

## Summary

Add a conversational Slack orchestrator that turns product discussions into structured Jira work and then implements that work autonomously.

A linked Slack user starts intake with:

```text
@Shoof jira
```

Bgagent immediately creates an app-authored Jira issue, reads the complete Slack thread, asks targeted clarification questions when necessary, and updates the Jira specification as the discussion evolves. Once the request satisfies a pragmatic readiness rubric, bgagent automatically starts implementation.

Large requests may become Jira epics or parent issues with dependent sub-issues. Progress, reactions, failures, and PR links are mirrored between Slack and Jira.

## User experience

1. Product discussion occurs in a Slack thread.
2. A linked user mentions `@Shoof jira ...`.
3. Bgagent reads the full thread and creates a Jira issue in the channel's configured project.
4. Bgagent reacts with 👀 and posts the Jira link.
5. If information is missing, it asks one focused question and reacts with ❓.
6. Human discussion may continue without waking bgagent.
7. A later `@Shoof` mention causes bgagent to read all intervening thread replies.
8. Bgagent continuously updates a structured Jira description and adds concise audit comments.
9. Once the work is actionable, bgagent reacts with ⏳ and starts implementation.
10. Large work may be decomposed into dependent Jira sub-issues.
11. Slack and Jira receive progress, failure, completion, and PR updates.
12. Requirements submitted after work starts are queued as a PR iteration.

## Product decisions

- Only explicit `@Shoof jira ...` requests start Jira intake; existing direct-task mentions remain unchanged.
- Subsequent mentions in the intake thread do not need the `jira` keyword.
- Mentions wake bgagent, but each turn reads the entire thread.
- The first linked requester remains the accountable task owner.
- Other linked users may add context and trigger reevaluation.
- Jira issues are created by the Forge app and cite the Slack requester and source thread.
- Jira project and repository routing come from configured Slack-channel and Jira-project mappings.
- Issue type is inferred from a configured allowlist, with Task as the fallback.
- Bgagent decides whether clarification, decomposition, or execution is appropriate.
- Readiness requires an inferable repository, intended outcome, scope boundaries, and testable success condition.
- Clarification receives a reminder after 24 hours and is abandoned after seven days of inactivity.
- Jira maintains a clean structured description plus concise audit comments.
- Slack reactions are 👀 received, ❓ needs input, ⏳ implementing, ✅ completed, and ❌ failed or abandoned.

## Delivery plan

This parent tracks three stacked implementation issues:

1. #833 — Conversational Slack-to-Jira intake and Jira drafting.
2. #834 — Jira decomposition, orchestration handoff, and queued follow-ups.
3. #835 — Dual-surface lifecycle, reminders, hardening, and documentation.

The issues are ordered serially: #834 is blocked by #833, and #835 is blocked by #834.

## Acceptance criteria

- [ ] A Slack thread can create and conversationally refine an app-authored Jira issue.
- [ ] Bgagent only processes the thread when explicitly mentioned.
- [ ] Jira execution starts automatically when the readiness rubric is met.
- [ ] Single issues and dependency-aware parent/sub-issue graphs are supported.
- [ ] The original Slack requester remains the platform task owner.
- [ ] Slack and Jira both receive consistent lifecycle feedback and PR links.
- [ ] Late requirements are queued and applied through PR iteration.
- [ ] Clarification reminders and abandonment are automatic.
- [ ] Existing Slack direct-task and Jira label-trigger flows remain compatible.
- [ ] Security, unit, construct, integration, and documentation checks pass.

## Out of scope

- Passive bot responses to every Slack message.
- Reading unrelated channel history outside the intake thread.
- Routing every Slack mention through Jira.
- Jira Server or Data Center.
- Interrupting and rewriting a currently running agent session.
- Requiring human approval before implementation begins.
- Jira projects or issue types outside configured allowlists.

Start with the stacked implementation issues #833, #834, and #835 to identify the intended work boundaries and dependencies. Use the acceptance criteria as the completion checklist; done requires the Slack-to-Jira lifecycle, orchestration, queued follow-ups, compatibility, security, tests, and documentation checks described here.

Written by the indexing model from the issue text.