Name the initiator where the fields a rule can use are listed

[Hotragn]

What this changes

#526 added initiator to the policy context so a rule can ask what started a run, and left both
places that tell an operator which fields exist saying nothing about it. A field nobody can discover
is a field nobody writes a rule against, which makes the previous change half-delivered.

Two lists, both now naming it:

• the Boundaries screen's own description of what a rule may ask about
• the field list in docs/architecture.md

Both carry the part that is not obvious from the name: actor.id on a scheduled run is the
routine's owner, so it cannot tell an unattended run from somebody typing, and initiator.kind is
the field that can.

Where it runs

• New state that outlives a request? None.
• What happens on the second replica? Nothing differs. This is prose.
• Anything serialised / fanned out / new listener? No, no, no.

Boundary and audit

No behaviour change. No rule evaluates differently, nothing new is refused or permitted, and no audit
row changes. This describes a field that already exists.

Changelog

None. A deployment behaves no differently afterwards — the field shipped in the previous release's
entry, and this only makes it findable.

Proof

app typecheck shows no error in the changed file, and biome format and biome lint are clean
on it.

Worth stating plainly: my local typecheck reports missing react-use-measure,
embla-carousel-react and @copilotkit/a2ui-renderer. Those are declared in app/package.json
and absent from my node_modules — a stale checkout on my side, not this change, and none of them
is the file I touched.

I have not seen the Boundaries screen render this. It is a sentence in an existing paragraph rather
than new markup, so the risk is wording rather than layout, but I would rather say so than imply I
drove it.

🤖 Generated with Claude Code

[davidmckayv]

Prose-only follow-up to #526; makes the initiator field discoverable. CI green.