test(codex): witness the stall instead of assuming it

The stalled-promotion test asserted runtime content plus mode, and the comment
called the content check load-bearing. It is not: when promotion succeeds it
writes the runtime change back to the system config and mirrors it straight
back, so 'gpt-5-codex' is present with or without a stall. Replicating the test
with only the chmod removed passed both assertions.

That matters beyond pedantry because chmod 0o500 does not restrict the owner
when running as root -- routine in CI containers. There, promotion would
succeed, the ordinary mirror path would run, the pre-existing repair would set
600, and the test would go green having covered nothing.

The system config NOT carrying the runtime model is the state only a stall
produces, so that is what the test now asserts.

src/main/codex/codex-config-mirror-file-mode.test.ts

@@ -141,8 +141,13 @@ describe.skipIf(process.platform === 'win32')('runtime config.toml file mode (ST
     try {
       syncSystemConfigIntoManagedCodexHome()
 
-      // The runtime content must survive: if it were overwritten, promotion did not stall and
-      // this would be exercising the ordinary mirror path, where the repair already ran.
+      // Witness that the promotion actually stalled. The runtime content alone cannot
+      // show it: a successful promotion writes the runtime change back to the system
+      // config and mirrors it straight back, so 'gpt-5-codex' is present either way.
+      // Its ABSENCE from the system config is what only a stall produces -- without
+      // which this test passes for the wrong reason wherever chmod does not bite,
+      // such as running as root in a CI container.
+      expect(readFileSync(systemConfigPath(), 'utf-8')).not.toContain('gpt-5-codex')
       expect(readFileSync(runtimeConfigPath(), 'utf-8')).toContain('gpt-5-codex')
       expect(modeOf(runtimeConfigPath())).toBe('600')
     } finally {