[argszero]

Closes #2722

What was wrong

emrg/server/ios_app_prompt.md says a great deal about method and nothing about how a capability question is answered. Searched on master 6f233a51, every spelling of the subject returned zero: official doc, documentation, developer.apple, deployment target, minimum os/minimum ios/minimum version, CI, downgrade.

That is the one claim in the task that can decide a direction on nothing. Two failures follow from it and both are silent: a limit remembered from an earlier release refuses a direction on a fact that may no longer hold — and the refusal is indistinguishable in the record from one that was measured — while a limit of the development machine is read as a limit of the user's device, which narrows the product to whatever the local toolchain happens to build.

What changed

A new subsection in Phase 3, #### 3.4 What the platform can do is looked up, not assumed, placed where the inception record fixes a direction's shape rather than appended at the end of the file. Six rules, each saying what a round does instead of what it believes:

• ask the platform's own documentation, not a recollection of it;
• a development machine's limit is not the user's device's;
• "it cannot be built here" is not "it cannot be done" — CI builds the matrix the host cannot, and its cost is not asserted from impression;
• a dependency that raises the minimum OS version is a product decision, taken to the host with the numbers rather than inside a round;
• a degraded implementation is not the feature — a downgrade is a missing segment (§3.1) wearing the core's name;
• state the conclusion so the host can repeat it back.

Written in the template's own voice: bold lead-in per bullet, no dates, no migration note, no reference to the installation the gap was observed on.

The guard

tests/test_prompt_templates.py gains two tests, in the shape the file already uses for this template:

• test_the_ios_app_template_answers_a_capability_question_from_the_platform reads §3.4 through _bounded_section — bounded at both ends, so a renamed closing heading fails instead of widening the region to the end of the file — pins six phrases, and asserts the lookup rule is stated exactly once in the whole template.
• test_the_ios_feasibility_pin_answers_both_ways deletes each pinned phrase in turn and asserts the pin reports it, so a section emptied of its content cannot read as passing.

How it was verified

• The arm, both directions: removing the 1,944-character section from the template reddens both pins (2 failed), and restoring it returns them green.
• The first attempt at that arm used -k "feasibility", which selects the control and not the main pin — one red in the helper, the named test never run. That reads like "caught" while the test meant to catch it was deselected, so the arm was redone with -k "capability or feasibility", whose collection output was printed first to show both node ids were selected.
• tests/test_prompt_templates.py — 64 passed; tests/test_host_blocked_browser_check.py + tests/test_scheduler.py — 181 passed (both read this template, and its the two stop-and-ask exceptions, money is spent and account settings change, are untouched).
• The per-template placeholder-rooted memory floor that pins ios_app_prompt.md at 2 still passes: the section names no memory path.

CI on this branch is pending; nothing here is claimed as verified by CI.