feat: add LexAI status bar and suggestion panel

- Implemented a status bar item for LexAI with dynamic status updates (ready, processing, notReady).
- Created a suggestion panel for displaying and interacting with AI-generated suggestions.
- Added functionality for accepting, regenerating, and discarding suggestions within the suggestion zone.
- Introduced configuration options for writing style, prompt patterns, personas, and formats.
- Integrated progress indicators for long-running tasks and improved user feedback.
- Established TypeScript configuration for the vscode package.

.cursor/skills/model-routing/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: model-routing
+description: Ask which models this project should run on, then bind the four routing lanes (lead, strong, mid, fast) into docs/MODEL_ROUTING.md and the model line of every .cursor/agents/*.md. Use at first initialization of a project, when the model lineup or plan changes, when a Task call fails with an unknown model, or when the sessionStart hook reports the lead model has drifted from the recorded lane.
+---
+
+Bind this project to real models exactly once, in one place, from what the operator can actually select — then let every other file refer to lanes. The kit ships unbound on purpose: every subagent carries `model: inherit`, so the roster works out of the box, but it also means the "cheap" scout costs exactly what the lead costs until this skill has run.
+
+Refuse to guess. Every ID written here must come from the operator's answer or from Cursor's model picker — never from the example families in `docs/MODEL_ROUTING.md`, and never from what a model was called at training time.
+
+## 1. Read the current state
+
+1. `docs/MODEL_ROUTING.md` — the lane table and its Status block. If `Routing filled` is already **yes**, this is a re-run: report the diff before writing anything.
+2. `.cursor/agents/*.md` — the current `model:` and `lane:` of each subagent. Count how many are still `inherit`.
+3. Whether the sessionStart hook reported a lead-model mismatch this session; if it did, that mismatch is the reason you were invoked and belongs at the top of your report.
+
+Never read, echo, or write an API key, and do not touch `~/.cursor/` — this skill's authority stops at the project.
+
+## 2. Ask the operator — one round, four questions
+
+Ask all four at once; do not interview one question at a time. Lead with what step 1 found so the operator is confirming, not composing.
+
+1. **Budget shape.** "Four distinct models, two, or one?" — this decides whether lanes collapse. One model in all four lanes is a valid, supported answer.
+2. **Strong lane.** "Which model should judge — critic, security-auditor, and any parity verdict?" Note that **Auto is not eligible here**: a router that may downgrade under load cannot be the independent judge the quality gates assume.
+3. **Lead lane.** "Which model do you want to drive the session yourself?" You cannot set this — it lives in the picker. Ask them to select it now so you can record what they actually chose.
+4. **Ceiling.** "Any cost, latency, or data-residency constraint that should keep work off a particular model?" A yes moves default lanes down; it never moves the gates.
+
+If the session is non-interactive (a Cloud Agent run, a headless `cursor-agent` invocation) and no answers were supplied, do **not** invent a routing: leave the kit unbound, record the request as a decision-ready item in `docs/PROGRESS.md` → *Waiting on you*, and stop. An unbound kit degrades to "everything runs on the lead's model," which is expensive but correct; a model ID that does not exist is a hard failure on the first Task call.
+
+## 3. Resolve real model IDs
+
+- Have the operator open the model picker and read back the exact IDs, or confirm the ones you propose from the profile table in `docs/MODEL_ROUTING.md`.
+- Availability follows the plan, not the docs: a model in the table that their account cannot select is not an option. Ask rather than assume.
+- Prefer Cursor's own Composer family for `mid`/`fast` unless the operator has a reason otherwise — it is trained for the builder loop and is usually the cheapest capable option.
+- The **gauntlet-critic** rides the `strong` lane and never a cheaper one: a referee weaker than the builder rubber-stamps. If the strong lane collapsed into mid, say so in the report and flag that every parity verdict now needs owner sign-off.
+- Cross-vendor lanes are a feature, not an inconsistency: a `strong` lane from a different vendor than `mid` gives you a genuine cross-model critic for free. Say so if the answers land that way.
+
+## 4. Write the routing everywhere it has to agree
+
+Two files must match, and the third place is a human action you cannot perform.
+
+1. **`docs/MODEL_ROUTING.md`** — replace `[LEAD]` / `[STRONG]` / `[MID]` / `[FAST]`, fill the Status block (plan, date, "verified against the model picker"), note any collapsed or degraded lane, and add a Change log row.
+2. **`.cursor/agents/*.md`** — for each file, read its `lane:` key and set the `model:` line from that lane. Change nothing else: not `name`, not `description`, not `readonly`, not `lane`, not the body. Leaving a file on `model: inherit` is a legitimate outcome when the operator wants that role to follow the lead — it is not a skipped file, and you must say which ones you left.
+3. **The model picker** — you cannot write it. Tell the operator plainly which model to select for the lead lane, and record their answer in the table.
+4. **`docs/DECISIONS.md`** — one ADR entry only when the routing embeds a real trade-off: a collapsed strong lane, a residency constraint, Auto on the lead. Skip it for an unremarkable four-lane fill.
+
+## 5. Verify before reporting
+
+Verification is mechanical — run it, do not assert it.
+
+1. `grep -rn "\[LEAD\]\|\[STRONG\]\|\[MID\]\|\[FAST\]" docs/MODEL_ROUTING.md` returns nothing.
+2. Every file in `.cursor/agents/` has a `model:` line whose value matches its `lane:`, or is deliberately `inherit`. List every mismatch.
+3. No model ID appears anywhere outside `docs/MODEL_ROUTING.md` and the agent frontmatter — `grep -rn` the four chosen IDs across `AGENTS.md`, `.cursor/rules/`, and `.cursor/skills/`. A hit there is the exact drift this kit is built to prevent.
+4. One live dispatch: send `scout` a trivial read-only task with the Task tool. A successful return proves the model ID, the account's access to it, and project-subagent discovery in one shot. An unknown-model error means step 3 used an ID this account cannot select — fix it now, not on the first real task.
+
+## Return
+
+**Routing** (the four lanes as written) · **Left on inherit** (which agents, and why) · **Files changed** (paths) · **Picker action for the operator** (the exact lead model to select) · **Verification** (the four checks and the live dispatch result) · **Degradations** (collapsed lanes, Auto on lead, unavailable models) · **Next action**.