fix: write output-schema temp file as the unprivileged user

[adityasingh2400]

When output-schema is passed and safety-strategy is unprivileged-user, the action fails with EACCES: permission denied while writing the temporary schema.json. The root cause is an ownership mismatch in resolveOutputSchema. The temp directory is created by running mktemp under sudo -u <codex-user>, so it is owned by the Codex user with the default 0700 permissions. The action then writes the schema into that directory with fs.writeFile, which runs as the action user (the runner). Because the directory grants nothing to its group, the runner cannot write into it and the run aborts before codex exec starts.

This change writes the schema file as the Codex user by piping the contents to tee under sudo -u, so the file is created and owned by the same user who later reads it via codex exec --output-schema. It mirrors the existing pattern where the final-message file written by the Codex process is read back with sudo -u <user> cat. Cleanup is updated to remove the Codex-user-owned temp directory with sudo rm -rf in the unprivileged path, matching how the temporary output file directory is already cleaned up; previously cleanup unconditionally used fs.rm as the runner, which would also have failed on that directory. The default (non-privileged) path is unchanged and still uses fs.writeFile plus fs.rm.

Validation: pnpm run check, pnpm test, and pnpm run build all pass, and the regenerated dist/main.js is committed so the CI dist-sync check stays green. The failure only manifests under sudo -u on a Linux runner with a separate Codex user, which the existing CLI-level test harness cannot exercise without that environment, so this follows the same no-unit-test pattern as prior runCodexExec/sandbox fixes in this repo.

Closes #103

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[adityasingh2400]

I have read the CLA Document and I hereby sign the CLA