feat(omp): add sync-solutions command documentation

.omp/commands/sync-solutions.md

@@ -0,0 +1,65 @@
+---
+description: Sync work/ leetcode solutions into docs/reference/ pages (gold standard format)
+---
+
+Sync every leetcode solution under `work/` into a docs page under `docs/reference/`, formatted exactly like the gold standard `docs/reference/01-reverse-string.mdx`. Extra focus (optional): $@
+
+## Inventory
+
+1. Glob `work/**/*.js`. Each filename is `<number>.<kebab-slug>.js`; the directory path is `work/<Difficulty>/<Category>/`.
+2. Glob `docs/reference/*.mdx`. A solution is already ported when a page's frontmatter title starts with the same leetcode number (`title: '<number>. …'`). Numeric filename prefixes (`01-`, `02-`, …) define sidebar order — never renumber existing pages.
+3. Build the todo list: one task per unported solution, plus one task per already-ported page whose `## Solution` code block no longer matches its `work/` source verbatim (update just the code block in that case).
+
+## Target path
+
+`docs/reference/<NN>-<kebab-slug>.mdx` where `<NN>` is the next unused two-digit prefix (continue from the highest existing one, in ascending leetcode-number order for the new batch) and `<kebab-slug>` is the slug from the work filename.
+
+## Page format — copy the gold standard exactly
+
+Every work file has a header comment block containing the problem statement, examples, constraints, and any follow-up. Transform it into:
+
+````mdx
+---
+title: '<number>. <Problem Name>'
+description: <first sentence of the problem statement, no trailing period>
+sidebar:
+  badge: '<Difficulty>'
+---
+
+<Badge variant="accent"><Topic></Badge>
+
+::::warning
+<the follow-up or special requirement, verbatim>
+::::
+
+### Example 1:
+- Input: `<input>`
+- Output: `<output>`
+- Explanation: <explanation with array/value literals wrapped in backticks>
+
+### Constraints:
+
+- `<constraint>` (inline code; keep plain prose like "nums is sorted…" with only identifiers in backticks)
+
+## Solution
+
+```js
+<the JSDoc comment and function from the work file, byte-for-byte verbatim — do not reformat, rename, or "improve" the code>
+```
+````
+
+Rules:
+
+- `<Topic>`: the problem's pattern category from the curriculum tables in `README.md` (e.g. "Two Pointers", "Hash-Based Lookup" → use "Hash Table", "Sliding Window", "Prefix Sum"). Fall back to the `work/` subdirectory name if the problem isn't in the README.
+- `::::warning`: only when the statement has a follow-up, in-place requirement, or similar special constraint. Omit the block entirely otherwise.
+- One `### Example N:` section per example in the header comment; include the Explanation bullet only when the source has one.
+- Exponents stay caret-style in inline code (`10^4`), matching the source comments.
+- Do NOT copy the header comment block into the page — only the JSDoc + function go in the code fence.
+
+## Verify
+
+1. `bunx blume build --isolated` must succeed with no new warnings; confirm each new route generated (`/reference/<slug>`).
+2. Spot-check one new page's built HTML for the badge, callout (when present), and solution code.
+3. `rm -rf .blume-verify` when done.
+
+Report a table: work file → docs page → created / updated / skipped (already in sync).