Why

TUI onboarding trusted-project persistence should go through the same app-server config write path as other config mutations. Writing config.toml directly from the trust widget bypasses that layer and can let onboarding proceed even when the trust decision was not actually persisted.

What changed

• Added a TUI config helper that writes the existing project trust structure through config/batchWrite.
• Persists trust decisions as projects.<project>.trust_level = "trusted" using the existing project trust key helper.
• Changed the trust directory widget to only record the user selection; onboarding performs the app-server write before reporting success.
• Keeps the user on the trust screen and shows an error if app-server persistence fails.

Verification

• cargo test -p codex-tui --lib trust_persistence_failure_keeps_trust_step_in_progress
• cargo test -p codex-tui --lib trusted_project_edit_targets_project_trust_level
• Manual: built the local codex-cli, accepted the trust prompt in a temp project, confirmed projects.<project>.trust_level = "trusted", and simulated an unwritable config to verify onboarding stays on the trust screen without writing trust.