Platform app move gap: Postgres apps have no home on the forge #11709

The forge will not run a managed Postgres per app; this pull records that decision and the two ways a Postgres app can still live here. It is docs only. I ran no tests or type check, and no code changed. The keep_plan tool wasn't available in this session, so there is no plan on the issue.

• Why no managed Postgres: an app's state is bun:sqlite under FORGE_APP_DATA, so production data, preview data, backup and restore are one directory each. A managed Postgres would add a server, per-app credentials, a network path out of the cell and a second backup story, for apps that are one process on one box. That would break the one-process, zero-dependency shape.
• Port path (the default): docs/APPS.md ("What is deliberately not here") now maps Postgres types to SQLite, moves queries behind one module, requires characterization tests before the switch, and loads the data from a pg_dump --data-only --inserts file. It then checks per-table counts and checksums.
• External path: for apps where the port isn't worth it (extensions such as PostGIS, data too large for one file), keep an outside Postgres. Its host goes in forge.json egress and the connection string is an app secret set by name. Previews must use a scratch database, and the owner backs it up, not the forge.
• Revisit trigger: if many apps end up on the external path, reopen the decision with that count.
• Other docs: docs/features/platform-app-move.md now links to the decision and marks #11698 decided rather than built. docs/EXTRACT.md has a one-line pointer to it.

What I did not do: I built no Postgres service and did not touch the import script from #11697. I did not try the port path on a real app, since I had no Postgres app or dump to run it on.

To try it, read "What is deliberately not here" in docs/APPS.md.

Closes #11698

The forge will not run a managed Postgres per app; this pull records that decision and the two ways a Postgres app can still live here. It is docs only. I ran no tests or type check, and no code changed. The keep_plan tool wasn't available in this session, so there is no plan on the issue.

• Why no managed Postgres: an app's state is bun:sqlite under FORGE_APP_DATA, so production data, preview data, backup and restore are one directory each. A managed Postgres would add a server, per-app credentials, a network path out of the cell and a second backup story, for apps that are one process on one box. That would break the one-process, zero-dependency shape.
• Port path (the default): docs/APPS.md ("What is deliberately not here") now maps Postgres types to SQLite, moves queries behind one module, requires characterization tests before the switch, and loads the data from a pg_dump --data-only --inserts file. It then checks per-table counts and checksums.
• External path: for apps where the port isn't worth it (extensions such as PostGIS, data too large for one file), keep an outside Postgres. Its host goes in forge.json egress and the connection string is an app secret set by name. Previews must use a scratch database, and the owner backs it up, not the forge.
• Revisit trigger: if many apps end up on the external path, reopen the decision with that count.
• Other docs: docs/features/platform-app-move.md now links to the decision and marks #11698 decided rather than built. docs/EXTRACT.md has a one-line pointer to it.

What I did not do: I built no Postgres service and did not touch the import script from #11697. I did not try the port path on a real app, since I had no Postgres app or dump to run it on.

To try it, read "What is deliberately not here" in docs/APPS.md.