feat(adapters): add conversational Slack-to-Jira intake and Jira draft authoring

## Parent

Part of #832.

## Summary

Implement the conversational intake foundation. An explicit `@Shoof jira ...` mention creates a Jira issue immediately, records durable intake state, evaluates the complete Slack thread, and either asks one blocking question or marks the intake ready for orchestration.

This issue stops at the readiness boundary; execution is delivered by the next sub-issue.

## Implementation

- Extend Slack channel mappings with:
- Jira cloud ID and project key.
- Allowed Jira issue types.
- Optional intake closure status.
- Reminder and abandonment timing overrides.
- Validate that the selected Jira project has an active project-to-repository mapping.
- Extend `bgagent slack onboard-channel` and setup documentation.
- Add Slack `channels:history` and `groups:history` scopes.
- Route `@Shoof jira ...` to a dedicated intake path while preserving existing task mentions.
- On subsequent mentions, identify the intake by workspace, channel, and root thread timestamp.
- Fetch the complete thread and process all new human replies since the previous evaluator turn.
- Add a dedicated DynamoDB intake table containing:
- Slack and Jira identities.
- Original requester and platform user.
- Normalized specification.
- Evaluator state and outstanding question.
- Transcript cursor and idempotency markers.
- Reminder/closure deadlines.
- Jira issue type and issue identity.
- Add a small-model Bedrock evaluator with validated, versioned structured output:
- normalized summary and description;
- problem, scope, constraints, and acceptance criteria;
- allowlisted issue type;
- `AWAITING_INPUT` or `READY`;
- one focused clarification question when blocked.
- Extend the signed Forge proxy allowlist with Jira issue creation and safe field updates.
- Create issues as the Forge app without requiring a linked Jira user.
- Include the Slack requester and source-thread reference in Jira.
- Rewrite the structured Jira description after each evaluator turn.
- Append concise Jira audit comments for questions and answers.
- Apply 👀 on receipt and ❓ when clarification is required.
- Ensure duplicate Slack deliveries cannot create duplicate Jira issues or evaluator turns.

## Acceptance criteria

- [ ] `@Shoof jira ...` creates exactly one Jira issue in the mapped project.
- [ ] Existing non-Jira Slack mentions retain their current behavior.
- [ ] Subsequent mentions resume the intake without requiring the `jira` keyword.
- [ ] Unmentioned replies never invoke bgagent.
- [ ] Each invocation sees intervening human discussion from the complete thread.
- [ ] Only linked Slack users can start or advance intake.
- [ ] The original requester remains the owner when collaborators participate.
- [ ] Jira issue types are restricted to the channel allowlist.
- [ ] Jira descriptions remain structured rather than becoming raw transcripts.
- [ ] Clarification produces one focused question and no coding task.
- [ ] The intake can reach a durable `READY` state.
- [ ] Jira and Slack API failures are retry-safe and user-visible.
- [ ] Handler, Forge, CLI, construct, and evaluator-schema tests pass.

## Out of scope

- Starting coding tasks.
- Creating Jira children or dependencies.
- Lifecycle mirroring after implementation starts.
- Reminder scheduling and abandonment execution.

Start with the Slack handler and the existing non-Jira mention path, then trace the Forge proxy, CLI onboarding command, constructs, and evaluator-schema tests named in the issue. Verify the acceptance criteria across intake persistence, thread processing, Jira creation, retries, and duplicate delivery handling; done means the handler, Forge, CLI, construct, and evaluator-schema tests pass.

Written by the indexing model from the issue text.