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

## 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 — #299 / #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).

Inizia in cdk/src/handlers/jira-webhook-processor.ts, intorno al guard per parent-attachment vicino alla riga 430 e alla costruzione di parent_context vicino alla riga 556, quindi segui i percorsi esistenti del grafo Jira e dello screening degli attachment. Esamina i test del processore/dell’orchestrazione Jira, degli attachment e della documentazione descritti nell’issue. Il lavoro è completato quando il contesto dell’Epic viene attribuito, sottoposto a screening, limitato e deduplicato al nuovo trigger, mentre gli altri adapter rimangono invariati.

Scritto dal modello di indicizzazione a partire dal testo della issue.