feat(fsi): add underwriting submission triage use case

[ckotikalapudi]

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

• 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

• 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.