[Security] Agent auto approve consent after timeout

[benniao85]

1. enable sandbox
2. try to read /write some files that are not in the default folder list
3. trigger agent to ask for consent

issues

1. after enable sandbox, agent randomly ask for consent for "System?" files
2. Instead of auto reject, agent auto approve the consent
3. No accept button for the consent, only Deny button

[yikkuro]

Verified against current main, including the Windows Node + MXC work merged through PR #216: unanswered permission requests fail closed and do not become approvals.

• The existing AppContainer file/shell/app permission path uses a 60-second timeout (SANDBOX_PERMISSION_TIMEOUT_MS = 60_000). Its timeout branches return deny, so the blocked operation remains denied.
• Ordinary Gateway approvals for Windows Node/MXC expire after 1,800,000 ms (30 minutes). Expiry resolves to no decision; the enforced MXC policy has askFallback=deny, so the command is reported back as Exec denied (..., approval-timeout) and node.invoke is not called.
• A timeout does not write a durable approval. Durable MXC records are created only after an explicit allow-always response with a fully bound command identity; deny and allow-once do not persist.
• Internal MXC readiness probes do not use the user permission queue. They use narrowly scoped, one-use proofs with a 15-second expiry; an absent, expired, replayed, or mismatched proof fails readiness and keeps ingress closed.

The relevant regression coverage includes constants.test.ts, sandbox-logic.test.ts, windows-node-mxc-durable-approvals.test.ts, openclaw-approval-replay-compat.test.ts, windows-node-mxc-readiness-proof.test.ts, bundled-windows-node-host.test.ts, PermissionDialog.test.ts, and the Windows-host approval/readiness tests. PR #216 also removes the pinned Gateway's expired implicit approval replay path by requiring a fresh valid approval.

Closing this as completed because the reported timeout-to-approval security behavior is not present in current main.