Policy slot: the fragment context

The FI policy for phase 3 judges its customer's fragment. Its context tree:

region per consumed record   (fields + stakeholders, 32 leaves each, up to 2)
region per created record    (same, up to 2)
region per consumed note     (asset, amount, owner kind, up to 2)
region per created note      (up to 2)
region flows                 (asset, amount, direction, counterparty_fi_index if known, up to 4)
region method                (program_id, template_id, method_id, instance, args[16])
region phase                 (phase = 3, time_bucket, roots, fi_index, chain_id, pool_address)
fragment_context_root = H(CTX_FRAGMENT, schema_id, region roots...)

Ctx<View> is generated per template. An accessor for a record exists only if the FI's customer is a stakeholder of that record, which the kernel has already proven, so the type-level rule of [Weld spec §5.2](/framework/core-types) carries over: no unwelded value is reachable, and no value the customer could not see is reachable. The app_context_root the method proves against is the same tree minus the phase region; K recomputes both from one plaintext.

Two actors from two FIs in one fragment yield two policy contexts over the same plaintext with different knowability, one W each.