feat(tui): add --dangerously-skip-permissions flag

[wqymi]

Summary

• Add --dangerously-skip-permissions to TUI mode (the default mimo [project] command), mirroring the existing mimo run --dangerously-skip-permissions flag.
• The flag sets MIMOCODE_DANGEROUSLY_SKIP_PERMISSIONS, which config.ts uses to inject an allow-all base ruleset under the user's permission config — so every tool auto-approves unless the user explicitly denied it. Explicit deny rules still win, matching the run flag's "auto-approve permissions that are not explicitly denied" semantics.
• Add a startup confirmation gate (mirroring Claude Code's bypass-permissions warning): a red warning + explicit "I accept the risks" select is required before the flag takes effect. Skipped when there is no TTY so automation still works; shows an extra warning when running as root.

Changes

• flag.ts: new MIMOCODE_DANGEROUSLY_SKIP_PERMISSIONS truthy env flag.
• config.ts: when set, mergeDeep({ "*": "allow" }, userPermission) so user rules (incl. denies) win.
• tui/thread.ts: new --dangerously-skip-permissions yargs option; interactive startup gate via promptDangerousPermissions(); sets the env var (post-accept) before the worker spawns so it propagates via sanitizedProcessEnv.
• i18n/en.ts + i18n/zh.ts: skip_permissions.* warning strings.
• thread.test.ts: extend the args fixture with the new option.
• cli.mdx: document the flag (also backfilled the previously-undocumented --never-ask and --trust).

Verification

• bun run typecheck — clean (also enforced by the pre-push hook, 12/12 tasks).
• bun test test/cli/tui/thread.test.ts — 2 pass.
• Semantics check: with { bash: "deny" } user config → bash evaluates to deny, edit to allow.
• All 6 new i18n keys resolve (en + zh).

Notes

• Unlike mimo run (which auto-replies to each permission prompt), the TUI version works by config injection, reusing the server-side permission evaluator. Consequence: a user's explicit deny rules are still honored (the safer reading of "not explicitly denied").
• The mimo run flag behavior is intentionally left unchanged.
• Root handling differs from Claude Code by design: rather than hard-refusing uid 0, it shows an extra root warning and still requires explicit accept (hard-refusing would make the flag unusable in root-only container environments).