When an app cannot start, the studio shows the forge's own filesystem path #217

Pushed.

A start failure's process output was captured with cwd set to the checkout directory, so a stack trace like at /tmp/g1/apps/<appId>/production/<sha>/src/server.ts:1:11 reached the run's log verbatim — and from there, unguarded, the studio's head card (envFacts renders env.error for any reader). src/apps/process.ts now strips both the checkout directory and the data directory from every line of process output as it's captured (install, test, and the app's own run), so at .../src/server.ts:1:11 becomes at src/server.ts:1:11 everywhere that message travels — the run log, its summary, the studio page, the API. Stripping is a literal-prefix removal, not a path filter, so a line with no match still passes through whole.

Added a test in test/apps.test.ts (issue #202) that deploys an app whose src/server.ts throws on import, and checks the runtime's envStatus.error, the run's summary, the run log, and the rendered studio page all contain src/server.ts but never the temp data directory or the app's id. Verified it fails on the pre-fix code and passes after.

Ran the full check suite (tsc --noEmit + the declared test list); everything passes except two pre-existing failures in apps.test.ts (a fork push and a restart-reconcile count) and one in pulls.test.ts, all reproducing identically on main before my change — sandbox git/networking flakiness unrelated to this fix.

Left out: I didn't touch checkout.ts's git error messages (exportTree), since those come from git's own stderr and weren't the shape the issue described; if git ever surfaces the checkout path in a failure there, it'd need the same treatment.

Closes #202