Orbit: "Trust this workspace (stop asking for routine commands)" does not stop asking for weak-tier models -- it only downgrades deny->ask

**Reported via beta feedback (v0.5.1, macOS/arm64, deepseek-v4-flash).**

> "When Orbit prompts the user to allow/deny a permission, it is unclear what it means to 'Trust this workspace'. Still, Orbit asks for permissions many times after clicking Trust this workspace. Not sure if this is a bug or whether better documentation would be helpful."

It's both -- and the label is the bigger half.

## Root cause

The option is labeled **"Trust this workspace (stop asking for routine commands)"** (`extensions/loom/exec-guard/gate.ts:119`). But in `extensions/loom/exec-guard/policy.ts` trust only relaxes the **unknown-command** category, **by one notch**, and the notch depends on model tier:

- `modelTier === "trusted"` -> `ask` becomes `allow` (genuinely stops asking)
- `modelTier === "weak"` -> `deny` becomes `ask` (**still asks, every time**)

It never lifts the catastrophic / workspace-jail / sensitive-read floors -- correct and by design.

So for a **weak-tier** model, trusting the workspace cannot ever stop the prompts; it only upgrades you from blocked to asked. The label promises "stop asking for routine commands" unconditionally, which for weak-tier models is never true.

This tester was on `deepseek-v4-flash`. `classifyModelTier` (`extensions/loom/exec-guard/model-tier.ts`) matches `WEAK_ID_MARKERS`, which includes `"flash"` -> **weak**. Their other model, `deepseek-v4-pro`, hits no weak marker and no `TRUSTED_ID_MARKERS` entry (deepseek isn't listed), so it falls through to the price test (`output >= 10` -> trusted); deepseek's output pricing is well under that, so it also classifies **weak**. Both of their models can never benefit from the trust option, which is exactly the reported experience -- ~24 `guard.decision` events in a few minutes after trusting.

## The ask

1. **Truth in labeling.** Don't promise "stop asking" when the current model's tier makes that impossible. Either reflect the tier in the label/description, or explain what trust actually grants ("unknown commands run without asking -- frontier models only; safety floors always apply").
2. **Explain the scope** somewhere reachable -- trust never lifts the catastrophic/jail/sensitive floors, so even on a trusted model some prompts are expected and correct.
3. Consider whether a weak-tier model should be offered the option at all, or offered a different one -- currently choosing it looks like a no-op to the user.

## Secondary (robustness)

Trust is stored and matched as an **exact string**: `trustWorkspace(cwd)` adds `ctx.cwd`, and `policy.ts` checks `req.config.trustedWorkspaces.includes(req.cwd)`. No normalization (trailing slash, symlink, case) and no subdirectory containment -- if `cwd` ever differs from the stored string by a character, trust silently stops applying with no signal. Worth hardening regardless of the labeling fix.

## Notes

Whether the remedy is "fix the label" or "grant weak models more" is a security/product call, not a mechanical fix -- flagging rather than assuming. Related: #233 (progressive/one-time grants + document yolo vs sandbox), #232/#247 (prompt fatigue), #317 (weak models behave differently under steering).

_(Beta tester feedback; usernames/paths/project names scrubbed.)_

Sibling: #378 (keyboard navigation on this same permission prompt) -- both touch the `ctx.ui.select` options in `gate.ts`, so a label change here and the keyboard affordance there should land coherently.

Read extensions/loom/exec-guard/gate.ts, policy.ts, and model-tier.ts, then trace how the trust option is presented and applied for each model tier. Resolve the intended security and product behavior before changing the label, scope explanation, or workspace matching; done means the UI accurately describes trust and the resulting behavior, including safety floors and weak-tier models.

Written by the indexing model from the issue text.