When a pull lands, its head's looks are kept as main's looks for each page, width and theme #9672

When a pull lands, the looks taken at its head are now copied and kept as main's looks for that page, kind and theme. One thing is untested: nothing yet shows that landing a real pull triggers the copy.

• Where they live: the copies are in main-looks/<app id>/ under the data directory, in the new src/looks/main_looks.ts. That folder is outside looks/, so the sweep that removes a closed pull's folder never touches it, and the app-level pruning of looks/ doesn't either.
• Reading them: mainLook(dataDir, appId, page, kind, theme) returns the file's path, or nothing if there isn't one.
• When it runs: the pull.merged branch of the looks service in src/looks/service.ts calls keepAsMain just before it forgets the pull's environment. A failure there is logged and never blocks the landing. A pull.closed without a merge keeps nothing.
• What gets copied: only pictures that were actually taken. Failed takes and looks a person attached are skipped, since those aren't what the page looks like.
• Replacement: each landing overwrites main's look for the slots it has. A page that only an earlier pull photographed keeps that pull's picture. Only main's latest is kept, never every head.
• Checks: test/main-looks.test.ts lands two pulls, deletes the first pull's looks/ folder as the sweep would, and checks three things. The second pull's home look replaces the first's. /about, photographed only by the first, keeps the first's look. Slots nobody photographed return nothing. tsc and scripts/gate.ts are clean.
• Pre-existing failures: test/looks.test.ts has three real-Chromium tests that fail in this sandbox (Chromium can't open a socket). They fail the same way without my change.
• Left out:

- The wiring from a real pull.merged event is not tested, because it needs a full app and pull fixture. - No page reads main's looks yet, as the issue asked. - A pull that merged while the forge was down gets no main look. - Files are the only record; there is no database table, to avoid a migration.

To try it, land a design pull on a preview that has looks, then check main-looks/<app id>/ in the data directory.

Closes #9668

When a pull lands, the looks taken at its head are now copied and kept as main's looks for that page, kind and theme. One thing is untested: nothing yet shows that landing a real pull triggers the copy.

• Where they live: the copies are in main-looks/<app id>/ under the data directory, in the new src/looks/main_looks.ts. That folder is outside looks/, so the sweep that removes a closed pull's folder never touches it, and the app-level pruning of looks/ doesn't either.
• Reading them: mainLook(dataDir, appId, page, kind, theme) returns the file's path, or nothing if there isn't one.
• When it runs: the pull.merged branch of the looks service in src/looks/service.ts calls keepAsMain just before it forgets the pull's environment. A failure there is logged and never blocks the landing. A pull.closed without a merge keeps nothing.
• What gets copied: only pictures that were actually taken. Failed takes and looks a person attached are skipped, since those aren't what the page looks like.
• Replacement: each landing overwrites main's look for the slots it has. A page that only an earlier pull photographed keeps that pull's picture. Only main's latest is kept, never every head.
• Checks: test/main-looks.test.ts lands two pulls, deletes the first pull's looks/ folder as the sweep would, and checks three things. The second pull's home look replaces the first's. /about, photographed only by the first, keeps the first's look. Slots nobody photographed return nothing. tsc and scripts/gate.ts are clean.
• Pre-existing failures: test/looks.test.ts has three real-Chromium tests that fail in this sandbox (Chromium can't open a socket). They fail the same way without my change.
• Left out:

- The wiring from a real pull.merged event is not tested, because it needs a full app and pull fixture. - No page reads main's looks yet, as the issue asked. - A pull that merged while the forge was down gets no main look. - Files are the only record; there is no database table, to avoid a migration.

To try it, land a design pull on a preview that has looks, then check main-looks/<app id>/ in the data directory.

I added the two tests you asked for and pushed them to the same branch. tsc and test/main-looks.test.ts pass.

• pull.merged (kept): the new test in test/main-looks.test.ts starts the real looks service on an app with a recorded look. It feeds the service a pull.merged event and checks that mainLook returns a copy with the head's content. It also checks that the pull's environment folder is gone afterwards.
• pull.closed (not kept): the second test feeds a pull.closed event and checks that mainLook returns nothing. The folder is still swept.
• Wiring check: I removed the keepAsMain call from src/looks/service.ts and the pull.merged test failed. I then restored the call.
• Synchronous copy: I added a note in the src/looks/main_looks.ts header that the copy runs synchronously on the event path. It is fine for a few PNGs and must not grow.

I didn't disagree with anything in the review.