emrg: the ios-app template puts every app in a subdirectory, which cannot be the root of its own repository #2488

What is observed

emrg/server/ios_app_prompt.md §0.6 opens with a layout rule, and §3 makes that rule the whole
of project inception:

Each app lives in its own workspace, <project root>/apps/<slug>/, and that directory is
host-readable.

A candidate that passed §2 becomes a project. Create the workspace (§0.6) and record, before
any code:

An installation whose apps are each a private GitHub repository of their own therefore reads two
instructions that cannot both hold. An app created at <project root>/apps/<slug>/ is a
subdirectory of a shared apps/ container, not the root of a repository — so it is not the app's
own repository at all. And apps/ is precisely the "one shared project holding several apps" that
the same installation forbids.

§0.1 already says instance values come from extra_prompt. The account an app's repository is
created under and the directory that holds it are such values, and §0.1's list does not name them,
so the two sides currently have no place to agree.

Why it matters

An app that ships is submitted for review, attributed (§4, "Attribution before submission"), and
may be archived or handed over. Each of those presupposes that the app's directory is a repository
with a history of its own. A directory inside a container has none: its history is whatever the
container's is, and a second app joining the container mixes the two.

§4's attribution rule makes this concrete rather than theoretical — "for anything worth sharing
later, note in the memory entry where the idea came from and under what licence any third-party
code, font or asset is used" is a record that only means something if the app can be handed over
as a unit.

What the fix must satisfy

1. §0.6 states that each app is its own repository, checked out as one directory directly under
   the project root and named after it, and that this directory is the app's workspace.
2. §0.6 refuses the two shapes that break it: a second app living inside the first app's
   repository, and a shared parent project holding several apps.
3. §0.6 states that only this app's directory is the task's to touch, because the directory the
   repository sits in may hold repositories that belong to someone else.
4. §0.1's list of extra_prompt values names the account an app's repository is created under and
   the directory that holds it, so the instance supplies them instead of the template guessing.
5. §3's inception step creates the app's repository and its directory, and no longer says only
   "create the workspace".
6. §0.7 states that build output stays inside the app's directory and out of version control — a
   trap that only exists once that directory is a repository.
7. A test names the layout line, so a later edit that restores the apps/ container reddens
   instead of passing silently.