fix: trust-gate project hooks and exec policies

[viyatb-oai]

Summary

• trust-gate project .codex layers consistently, including repos that have .codex/hooks.json or .codex/execpolicy/*.rules but no .codex/config.toml
• keep disabled project layers in the config stack so nested trusted project layers still resolve correctly, while preventing hooks and exec policies from loading until the project is trusted
• update app-server/TUI onboarding copy to make the trust boundary explicit and add regressions for loader, hooks, exec-policy, and onboarding coverage

Security

Before this change, an untrusted repo could auto-load project hooks or exec policies from .codex/ as long as config.toml was absent. This makes trust the single gate for project-local config, hooks, and exec policies.

Stack

• Parent of fix: enforce trusted-before-project ordering for hooks #15936

Test

• cargo test -p codex-core without_config_toml

[eternal-openai]

Hey ok, thanks your patience -- I've reviewed this as best as I could, and it looks good though a few notes:

• this does slightly change execpolicy semantics, though I think for the better
• windows tests should probably be enabled, since we more recently tested that everything works fine on windows with hooks & re-enabled the feature for windows
• there's a minor but potentially important issue with aliases and the hashmap:

Before this PR, the lookup had a clear rule:

1. try the canonical path key
2. if that misses, try the raw path key
3. So if the config had both entries, there was still a deterministic winner: canonical first.

This PR changes that into:

1. expand every configured project into all its alias keys
2. insert all of them into a new HashMap
3. later, look up whichever key matches

That sounds tidy, but it creates a collision problem. If config contains two entries that alias the same repo and disagree, both write to the same normalized key. One overwrites the other

[projects."/work/repo"]
trust_level = "trusted"

[projects."/tmp/link-to-repo"]
trust_level = "untrusted"

If /tmp/link-to-repo resolves to /work/repo, the new code can collapse both onto the same lookup key. Now the effective answer becomes “whichever entry won the overwrite,” instead of a defined policy.

[viyatb-oai]

Thanks for the detailed pass. I agree with the notes.

• The execpolicy behavior change is intentional: project-owned policy should only participate once the project config layer is trusted, so an untrusted checkout cannot widen execution behavior.
• I agree on Windows coverage. I had temporarily skipped the two tests while debugging the Windows hook runner, but since hooks are enabled there now, I will re-enable them and make the fixtures pass on Windows instead.
• The alias collision is a good catch. I will fix the lookup to keep the prior deterministic precedence semantics (canonical path first, then raw path) rather than relying on alias-expanded HashMap insertion order. If two configured entries resolve to the same canonical project, the effective winner should be defined, not incidental.

I will patch those before merge.