Platform contract: toolkit-bound file assets + agent file output

[dimitri-tombroff]

Platform contract: toolkit-bound file assets + agent file output

Why

Toolkits increasingly need to (a) attach a file at agent-configuration time and
(b) produce a file for the user at runtime. Today each feature invents its own
storage location, access rules, and download path. This issue defines that once,
as a reusable contract, and validates it with the PPT Filler epic as first consumer.

What this issue decides (the seam)

1. Asset location — canonical path/namespace for a config-time toolkit asset,
   built on the unified filesystem (the four roots), with the one-asset-per-agent
   key convention.
2. Permission model — who may upload/replace a toolkit asset, who may read it,
   and who may read an agent's generated output (ReBAC-governed).
3. Download authorization — generated output is returned as a signed,
   short-TTL, session-authenticated LinkPart(kind="download").

What stays out of scope here

All PPT-specific logic — parsing, the placeholder grammar, the fill traversal,
the per-slide schema — lives in the consumer epic and is unchanged.

First consumer

The ToolkitAssetProcessor and ppt_filler work (#1830–#1834) consumes this
contract: its asset storage and runtime output resolve to the locations and
permissions defined here instead of defining their own.

Done when

• The three decisions above are written into FILESYSTEM.md /
  RUNTIME-EXECUTION-CONTRACT.md.
• PPTFILL-04: Generic ToolkitAssetProcessor seam + atomic save #1833 (asset processor) and PPTFILL-05: Fill tool — dynamic per-slide input + filled-deck download #1834 (fill tool) reference this contract for
  storage + download instead of ad-hoc phrasing.