QM-32: create the software factory loop when the factory config is applied

[pcapriolo-yc]

Closes QM-32.

Changes

Why this matters: The software factory could be configured but never actually existed. Nothing in the system could create a loop carrying the factory surface, and that surface is the only gate on every factory code path, so an operator could fill in the "Software factory" admin card, click Apply, and get nothing but stored settings. Turning the factory on now brings the factory into existence.

What changes:

• Applying factory-config on an org scope (the "Software factory" admin card) now also creates a "Software factory" loop owned by the applying admin at that org scope, which appears on the loops page and can be opened, fired, paused, and put on autopilot like any other loop.
• Applying again is idempotent: the same config, a changed config, or a second admin applying all leave exactly one factory loop with its original id and owner.
• Clear ({ "reset": true }) removes the configuration only and leaves the loop standing; a rejected apply (invalid body, non-org scope, unauthorized actor) behaves exactly as before and creates no loop.
• The loop declares the ship actions the factory actually emits, open_pr and close_already_fixed, both gated on auto, so a converged run ships without a human click: the review happens on the pull request, not on the loop output.

Acceptance stories:

• As an org admin, I apply the factory configuration and get a real "Software factory" loop I can open and fire; before, Apply saved settings and created nothing.
• As an org admin, I apply the configuration repeatedly, unchanged or changed, and still see exactly one factory loop with the same id and owner. A second org admin's apply also creates no second loop, but that admin cannot yet see or administer the loop over HTTP: canAdministerLoop has no org branch, so only the first applying admin passes. That widening is a separate change.
• As an org admin, I click Clear and the configuration is gone while the loop stays, so re-applying restores a working factory without duplicating it.
• As an admin submitting an invalid or non-org-scoped configuration, I get the same rejection as before and no factory loop is left behind.
• As Quartermaster firing the factory loop, I now reach the factory effects — previously unreachable code — and fail on missing factory credentials rather than having no loop to fire at all.

Test Plan

• NODE_ENV=test ALLOW_UNSIGNED_TEST_IDENTITY=1 node --experimental-test-module-mocks --test test/loop-factory-loop.test.ts
• NODE_ENV=test ALLOW_UNSIGNED_TEST_IDENTITY=1 node --experimental-test-module-mocks --test test/admin-resources.test.ts
• NODE_ENV=test ALLOW_UNSIGNED_TEST_IDENTITY=1 node --experimental-test-module-mocks --test test/loop-factory-wiring.test.ts
• npm run lint
• Manual: in a browser against a live instance, filled in and applied the "Software factory" admin card at an org scope, confirmed the loop appears on the loops page, that a second apply adds none, that Clear leaves the loop, and that Fire now and Autopilot work on it.

Proof it works

All seven acceptance stories pass, verified in a browser against a live instance and backed by green targeted test runs.

page@0c3cf56c3172d9b36dc6e06b01ea5b24.webm — /tmp/claude-recordings
page@76ceaf47be3a6f35de0415b201a784d1.webm — /tmp/claude-recordings

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}