feat(fsi): add underwriting submission triage use case

## Feature Description

Add an **underwriting submission triage** use case to FSI Foundry: commercial P&C
insurance submission triage that screens a broker's submission against the
insurer's written risk appetite, quantifies aggregate exposure and loss history,
and produces a technical price indication — reconciled into a quote / refer /
decline decision.

## Use Case

Underwriters receive far more submissions than they can analyse and win only a
fraction of what they quote, so the critical skill is triage: declining early
rather than after two days of analysis. Today that first pass is manual, applies
appetite inconsistently, and produces findings that don't cite the rule they came
from — which is what a peer reviewer or regulator needs.

FSI Foundry has no commercial P&C pre-bind scenario. The existing insurance use
cases are `claims_management` (post-bind) and `life_insurance_agent` (life).

## Proposed Solution

Three specialists running concurrently under a fan-out / synthesize orchestrator:

1. **Appetite Screener** — IN_APPETITE / OUT_OF_APPETITE / REFERRAL_REQUIRED,
every finding citing its rule id
2. **Exposure Analyst** — total insured value, catastrophe concentration,
prior-claims frequency and severity
3. **Pricing Indicator** — technical premium, rate per thousand, expected loss
ratio, items required from the broker

Three decisions shape the design:

- **The appetite ruleset is data, not prompt or config.** Rules live in each
submission's compliance record, so they change without a code change and each
finding cites its rule id. The prompt teaches how to evaluate a ruleset, not
the rules themselves.
- **Appetite outranks pricing.** A prohibition breach is dispositive; pricing can
never upgrade an outcome.
- **Only `full` mode returns a decision.** Appetite alone can decline but never
quote; exposure or pricing alone cannot decide either way. Partial modes leave
`decision` unset rather than asserting an outcome from a third of the evidence.

Sample data is graded so each path is exercised against an identical ruleset: a
clean quote, a referral, and a decline. The clean one passing matters — it shows
the screening discriminates rather than flagging everything.

## Alternatives Considered

- **Rules in the prompt or config** — would need a code change to edit, and
findings couldn't cite a rule id.
- **Averaging the three assessments** — lets an attractive price soften a
prohibited risk. Explicit precedence instead.
- **Short-circuiting on appetite failure** — deferred. Needs structured per-agent
output in `StrandsOrchestrator`; results are currently free text, so control
flow can't safely branch on them. Belongs in the base class, not one use case.
- **Document (PDF) inputs** — deferred. Real submissions are broker attachments;
intended shape is hybrid, keeping insurer system data as JSON.
- **Strict enum validation on responses** — one formatting slip (`"Quote"` for
`"quote"`) would discard the whole structured result. Request-side validation
is strict.
- **A `langchain_langgraph` mirror** — out of scope; the router rejects it
explicitly rather than failing on a confusing import error.

## Implementation Complexity

- [ ] Low - Simple addition

- [x] Medium - Moderate changes required

- [ ] High - Significant architecture changes

Large surface but purely additive: extends `StrandsOrchestrator` and reuses
`s3_retriever_tool` without touching any shared abstraction. Only pre-existing
file changed is the registry. The one item needing an architecture change (the
appetite gate) was scoped out for that reason.

## Related Phase

- [ ] Phase 1 - Foundation

- [ ] Phase 2 - IaC Variety

- [ ] Phase 3 - Tools & MCP

- [ ] Phase 4 - Multi-Pattern

- [ ] Phase 5 - Composition

- [ ] Phase 6 - Advanced Config

- [ ] Phase 7 - Marketplace

- [ ] Phase 8 - Enterprise

- [x] Other

## Additional Context

Implementation is ready, following the existing use case structure (Strands
orchestrator + agents, graded S3 sample data, registry entry, React/Vite UI,
AgentCore integration test).

The integration test asserts exact outcomes, not plausible ones — the samples are
an answer key derivable from each submission's own ruleset. Two negative
assertions carry as much weight as the positive ones: one risk must *not* trip
the frame-construction rule, another must *not* report named-storm concentration.
Blanket-failing a risk is as wrong as missing a breach.