emrg: the ios-app template never says the app's repository is private, and never fixes its name #2523

emrg/server/ios_app_prompt.md §0.6 "Workspace hygiene" is where an app's repository is defined. It says each app is "its own repository", created before the first line of code, checked out as <project root>/<repo>/, and that a second app never joins the first one's. §3 then says "Create its repository and its directory (§0.6)", which makes §0.6 the authority for creating it.

§0.6 answers where the repository goes and how many apps may share one. It answers neither property that decides what that repository is:

1. Visibility. Nothing in the template requires the repository to be private, so a round following §0.6 literally can create a public one. An app that has not passed review is not public material: its source, the store listing being prepared, the review notes, and the evidence behind a direction that §5's second checkpoint later abandons would all be published permanently, before the round knows whether the direction survives.

2. Name. "named after it — <project root>/<repo>/" constrains the directory's position, not the name's form: a codename, a title-case spelling, a date or a version stamp all satisfy it. §3's inception record and §7's per-app memory entry are re-read by a later round that has only the name to go on, and the App Store product name is the one label the host and that later round both hold — so a name that is not that name in a fixed form is a name that has to be decoded.

Expected. §0.6 states both properties, in the section that already owns the app's repository and in the template's own voice: the repository is private, and its name is the product's name, lower-case and hyphen-separated. The account the repository is created on stays an extra_prompt value (§0.1) — the template hard-codes no owner, path or budget.

What the fix must satisfy.

• Both rules live in §0.6, not appended at the end of the file, and neither is stated twice.
• No instance value enters the template.
• A test pins each rule by phrase inside §0.6's bounded region, and the pin answers both ways: removing a phrase makes exactly that phrase read as missing, and claiming the opposite of the privacy rule reads as missing too.