A step that is the host's needs a browser self-check first, and a named blocker #2716

What was observed

EMRG's task templates divide into two groups on one question — before an agent tells the host that
a step is the host's own, does it check the state for itself?

• competition_prompt.md carries a browser-first rule (:40), and also a blocked table whose row
  reads "Needs a human action (real-name, SMS, card authorization) → Write into blocked with what
  the host must do", and a Blocked (host action required) table with a what the host must do
  column (:124, :335, :403).
• promote_prompt.md (three rules) and journal_prompt.md (one) also carry browser-first.
• open_source_prompt.md — the template for contribution-platform work — carries no browser rule at
  all, across 469 lines, although its subject is exactly where account state lives: a CLA record, a
  contribution agreement already signed years ago, a repository setting, a maintainer-only page.

So the two templates that hand work back to the host write the hand-back without a rule that the
state be checked first, and the template whose subject is platform account state has no browser rule
in it whatsoever.

The failure this permits has already happened, and its cost is recorded: an agent concluded that a
blocked CLA meant only the host himself could sign it and handed the work back. The host asked it to
look in the browser instead, and the real cause was an empty author email on the commits — fixable
entirely from the CLI. The conclusion was wrong, and it was wrong in the direction that spends the
host's time.

What is expected

One rule, stated where a cycle decides what it can and cannot do, and present in every template that
can hand a step back to the host for a capability reason:

1. A web-UI-only state is checked in the real browser before any conclusion that the step is the
   host's. Third-party account status, signature and agreement records, forms, settings pages — the
   login state exists only in the real browser, so an API or CLI probe answers about a logged-out view
   and is not evidence about the account.
2. A fallback names the step that blocks. "Only the host can do this" is a conclusion that needs a
   fact behind it: which exact action fails, and why automation cannot perform it (a password only the
   host knows, a 2FA prompt, a legal-entity signature).
3. The rule is about capability, not about permission. A template that stops because a step would
   spend money or change the host's account settings is stating an authorization boundary, and that
   stop stays exactly as it is — the browser check is not a licence to do those things.

Acceptance

• open_source_prompt.md states the rule, in the section that already owns "what this environment can
  and cannot do" (§3.1.6), in the template's own voice, with no history and no citation.
• competition_prompt.md's host-blocked row carries the same obligation: the state is checked in the
  browser before the row is written, and the row names the blocking step.
• A test compares the two carriers both ways — the same requirement is what both state, so a later
  edit to one of them alone reddens the test rather than silently splitting the rule.
• ios_app_prompt.md's two "stop and ask the host" exceptions (money, account settings) are
  untouched: they are permission boundaries, not capability claims.
• Deleting the clause from either carrier reddens the test.