Automate a review finding as a lint or test: The pull is a billing feature while the direction is pipeline-first; keep it sma #12365

The gate now refuses a feature pull that goes ahead of the pipeline but isn't small and single-purpose, which is what the four review comments kept asking for. bun scripts/gate.ts and tsc --noEmit pass; I ran only test/direction.test.ts and test/direction-refusal.test.ts, which pass. I did not run scripts/fast.ts or the full suite.

What changed

• The gap: The existing "pipeline first" rule (#11036) only asked a feature pull for a Direction: <why> line. Once the line was there, nothing limited the pull's size. The four reviews on #11289, #11696, #12177 and #12307 each accepted a waiver and still said "keep it small".
• The new limit: In src/kernel/direction.ts, a pull that adds a feature surface and has no pipeline change may now add at most 2 feature files and change at most 20 files in all. The 2-and-20 limits are my judgement, not set by the issue, so say if they should be different.
• The failure message: It names rule "small and single-purpose", says what exceeded the limit, and tells the author to split the pull or change the pipeline. scripts/gate.ts already runs this check, so it needed no change.
• The test: A new case in test/direction.test.ts fails without the new rule. It covers the passing case, both the too-many-features and too-many-files failures, and a pipeline change lifting the limit.

Left out

• What counts as "single-purpose": It is measured by file count only, since the gate cannot judge intent. A pull of up to 20 files that mixes purposes still passes.
• The check on this branch: I haven't seen the forge's check run on this push.

To try it Add three files under src/web/pages/ with a Direction: commit line, then run bun scripts/gate.ts.

Closes #12363

This pull's check was red on two kinds of failure, and I've fixed one of them; the other I couldn't run here. I pushed the fix and haven't seen the new check result yet.

• Data browser audit (fixed): data browser core > every forge.db column that could hold a secret… failed because two new columns from main's migrations weren't in AUDITED_CLEAR in test/data-browser.test.ts.

- app_env.value_plain is the plain-variable column; secrets stay sealed in value_enc. - secret_start.value_updated_at is only a timestamp. - I added both to the list. The test passes with the new entries, and tsc --noEmit is clean. Nothing else changed; the pull's own code change, in src/kernel/direction.ts, is untouched.

• Cell spawn test (not verified): a child forge spawned into a cell serves its app at <app>--<child>--<parent> is skipped in this sandbox because cells can't run here. It was already filed as flaky under #10683, and nothing in this pull touches spawn code. I made no change for it, so it may still fail on the forge's check.
• Remaining failures (not looked at): the log named only these two of the seven failed tests, so I haven't seen the other five.

I merged origin/main into the branch before fixing, because it was 40 commits behind.