feat(jira): fold Epic context into child Issue/sub-issue tasks

[ayushtr-aws]

Component

CDK Jira adapter, orchestration parent_context propagation, Jira context hydration, attachment screening

Describe the feature

When ABCA orchestrates authored Jira subtasks, a child task should be able to inherit context from its Epic (grandparent), not just its immediate parent Issue. Today context inheritance only travels one level up: a sub-issue receives its parent Issue's title/description, but the Epic's description and attachments never reach it.

Use case

Teams frequently put the authoritative design detail — spec text, diagrams, linked docs, screenshots — on the Epic, then break work into Issues and sub-issues that carry little standalone detail. When the agent implements a sub-issue two levels below the Epic, it can't see that Epic-level context, so it works with less information than a human reviewer would assume it has. (Reported by a user: Epic attachments were not accessible to the agent implementing a child Task.)

Current behavior

In cdk/src/handlers/jira-webhook-processor.ts, releaseContext.parent_context is built from the triggering issue's own summary and descriptionMarkdown (~:556), and pre_screened_attachments are the triggering issue's attachments. Children inherit only that immediate parent's text — the Epic's description and attachments are not resolved or propagated.

Proposed solution

• Resolve the Epic (grandparent) for an orchestrated Jira Issue/sub-issue via the existing Jira graph source.
• Include the Epic's description in child task context, clearly attributed/scoped as Epic-level context (distinct from the parent Issue's context) so the agent can weight it appropriately.
• Optionally propagate the Epic's attachments as pre-screened attachments to child tasks, routed through the existing attachment screening / SSRF / Guardrail pipeline and subject to current per-task attachment limits.
• Pin Epic attachment S3 versions once (mirroring the existing parent-attachment re-upload guard at :430) so re-triggers don't duplicate or expire pinned objects.
• Make Epic-context inheritance bounded and predictable: one Epic level, with clear precedence rules when Epic and Issue context conflict.

Acceptance criteria

• A Jira sub-issue task whose Epic has a description receives that Epic description in its context, labeled as Epic-level.
• Epic attachments, when propagated, are screened through the existing pipeline; unsupported/too-large/blocked/unscreenable attachments do not reach the agent (fail-closed consistent with today).
• Combined attachment limits are respected across Epic + Issue + sub-issue sources (no silent overflow — dropped items are logged).
• Re-triggering an existing Jira orchestration does not re-upload or duplicate Epic attachments.
• Linear, GitHub, Slack, and API task context behavior is unchanged.

Tests

• Jira processor/orchestration tests cover Epic resolution, Epic-description inclusion, and Epic-attachment propagation with attribution.
• Attachment tests cover Epic-attachment screening failures and the combined-limit / re-trigger de-dup paths.
• Docs describe what Epic-level context is included and its precedence relative to Issue-level context.

Out of scope

• Automatic decomposition of an Epic into Issues/sub-issues (bgagent:decompose, tracked separately — feat(linear): auto-decompose issues into a dependency-aware sub-issue graph (plan + approval) #299 / feat(github): support bgagent:decompose and bgagent:auto planning labels #586).
• Context inheritance beyond one Epic level (great-grandparents, cross-Epic links).
• Fetching arbitrary linked/referenced issues that are not the Epic ancestor.
• Any non-Jira adapter (GitHub, Linear, Slack, API).