Remove locale-compare; misc cleanup and dependency bumps

- Replace locale-compare with native Intl.Collator in sort_object.ts and build_json.ts
- Switch bun:path and bun:util imports to node:path and node:util
- Bump @types/bun, eslint, globals, typescript-eslint
- Add JSDoc to simplify() and sortObject()
- Tighten sortObject return type, type the sorted object
- Streamline reflect and suggest prompt files

Author: bhousel

.github/prompts/commit.prompt.md

@@ -1,5 +1,6 @@
 ---
-description: Stage and commit all changes in this repo
+description: Stage, commit, and push all changes in this repo
+argument-hint: commit detail to include, for example: `(closes ​#123)`
 ---
 
 You are performing a git commit for this repo. Do the following steps in order:
@@ -16,4 +17,9 @@ You are performing a git commit for this repo. Do the following steps in order:
      git commit -F /tmp/commitmsg.txt
      rm /tmp/commitmsg.txt
      ```
+   - If a commit detail argument was provided (e.g. `closes #123`), include it on its own line after the first line (subject), separated by a blank line:
+     ```
+     printf '%s\n' 'First line' '' 'closes #123' > /tmp/commitmsg.txt
+     ```
 5. Run `git push` to push commits up to the origin
+

.github/prompts/reflect.prompt.md

@@ -1,72 +1,20 @@
 ---
 description: Reflect on recent work and bring all project documentation up to date
+argument-hint: additional optional context
 ---
 
-You are doing a documentation update pass. Recent code changes may have left docs, guides, and inline comments out of date. Your job is to find and fix those gaps — not to write new documentation for its own sake.
+Update all project documentation to match the current state of the code. Fix gaps, stale content, spelling mistakes, and anything unclear. Make all edits — do not just list findings. Do not commit; the user will review first.
 
-**Do not commit.** Make all edits and stop. The user will review before committing.
+## Steps
 
-## How to approach this
+1. Read `AGENTS.md` to understand the project structure.
+2. Review the current chat session history — primary source of context for what changed.
+3. Run `git log --oneline -20` to confirm what was actually landed.
+4. Search the codebase as needed to verify current state.
 
-First, get oriented:
-1. Review the current chat session history — this is your primary source of context for what was discussed, decided, and changed
-2. Run `git log --oneline -20` to see recent commits and confirm what was actually landed
-3. Use `#codebase` to survey the current state of the project
+## What to update
 
-Then work through each documentation layer below.
-
----
-
-## Documentation layers to check
-
-### SCRATCHPAD.md (if present)
-A working-memory file for agents (gitignored). Update it with:
-- Any new quirks, gotchas, or lessons learned from recent work
-- Any known issues or follow-up tasks worth remembering
-- Remove anything that is now resolved or stale
-
-### AGENTS.md (if present)
-Agent context file. Check that:
-- The described project structure still matches reality
-- Any tool, script, or workflow guidance is still accurate
-- Nothing important from recent work is missing
-
-### README.md
-The public face of the project. Check that:
-- The feature list / description still reflects what the project does
-- Setup and usage instructions still work as written
-- Any referenced scripts, commands, or file paths still exist and are correct
-- Version numbers or compatibility notes aren't stale
-
-### CONTRIBUTING.md (if present)
-Check that:
-- Development setup instructions are still accurate
-- Any described workflow (build steps, naming conventions, PR process) reflects current practice
-
-### Other markdown files (CHANGELOG.md, RELEASE.md, etc.)
-- CHANGELOG: verify the most recent entry matches the current `package.json` version (or equivalent). Flag if they're out of sync — but do not generate a new changelog entry here; that's for `/release`.
-- RELEASE.md or similar: check that documented release steps match current tooling
-
-### Prompt files (`.github/prompts/*.prompt.md`, `.instructions.md`, etc.)
-Check that:
-- Referenced file paths, script names, and commands still exist
-- Any example version numbers or outputs are not misleading
-- Steps are still in the right order
-
-### Inline code documentation
-Look for comments in source files that reference something that has since changed:
-- Outdated file paths or module names
-- Comments describing behavior that has been refactored
-- TODO/FIXME comments that have been resolved by recent work (remove or update them)
-
----
-
-## How to respond
-
-For each layer, report one of:
-- ✅ **Up to date** — nothing to do
-- 🟡 **Updated** — briefly describe what you changed
-- 💡 **Flag for user** — something needs a human decision (e.g. a CHANGELOG version mismatch, a structural README question)
-
-Keep it brief. One line per finding is enough.
-Make all edits directly — don't ask for permission on small fixes.
+- Inline documentation (JSDoc, comments)
+- Markdown files (`README`, design docs, contributing guides)
+- Agent instructions (`AGENTS.md`, `copilot-instructions`, etc.)
+- Working memory (`.scratchpad/*`)

.github/prompts/suggest.prompt.md

@@ -1,59 +1,43 @@
 ---
-description: Review the codebase and suggest (then implement) concrete improvements
+description: Review the codebase and suggest improvements
+argument-hint: additional optional context
 ---
 
-You are doing an improvement review of this codebase. The goal is to find **concrete, actionable improvements** — not a wishlist. Think like an experienced senior engineer or architect who respects the existing style and doesn't over-engineer.
+Find concrete improvements and flag things worth tracking for future work. Respect the existing style; don't over-engineer. Report findings only — do not make edits. The user will choose which suggestions to implement.
 
-## What to read first
+## Steps
 
-Get a broad picture of the project before forming any opinions. Use `#codebase` to survey the whole workspace — pay particular attention to:
-- Package/dependency manifests (`package.json`, `Cargo.toml`, `pyproject.toml`, etc.)
-- Compiler/type-checker config (`tsconfig.json`, `mypy.ini`, etc.)
-- Runtime/bundler config (`bunfig.toml`, `vite.config.*`, etc.)
-- Build and tooling scripts
-- The README — how the project presents itself and what it's for
-
----
+1. Read `AGENTS.md` to understand the project structure.
+2. Survey the codebase, paying particular attention to:
+   - Package/dependency manifests (`package.json`, etc.)
+   - Compiler/type-checker config (`tsconfig.json`, etc.)
+   - Runtime/bundler config (`bunfig.toml`, etc.)
+   - Build and tooling scripts
+   - `README` — how the project presents itself
 
 ## Categories to evaluate
 
-For each category below, look for real issues and note them. Skip categories where things look fine — don't invent problems.
-
-**Correctness / bugs**
-- Are there any scripts or config values that are plainly wrong? (e.g. calling `npm run` in a Bun-only project)
-- Any TypeScript errors or implicit `any` types?
-- Any typos in user-facing strings (error messages, log output)?
+Skip categories where things look fine. Don't invent problems.
 
-**TypeScript quality**
-- Are types as precise as they should be? (e.g. `String[]` vs `string[]`, missing type annotations on parameters)
-- Are there untyped third-party modules that need a `.d.ts` declaration?
-- Are there `tsconfig.json` options enabled that don't apply to this project?
+**Correctness / Bugs** — wrong config values, broken scripts, typos in user-facing output
 
-**Runtime / tooling overlap**
-- Does the project use Node.js APIs where a Bun-native equivalent exists and is simpler? (e.g. `node:fs` vs `Bun.file()`)
-- Are there npm/yarn artifacts in the scripts that should use `bun`?
-- Are there dependencies that Bun now handles natively (e.g. a test runner, a bundler)?
+**Code Quality** — outdated practices, duplicated logic, unnecessary indirection, misleading comments, obvious simplifications
 
-**Dev experience**
-- Is there a fast linter+formatter that would be easy to add? (Biome is a good fit for Bun projects — one tool, zero config, very fast)
-- Are there missing or misleading `package.json` scripts?
-- Is the `.gitignore` / `.gitattributes` complete and correct?
+**Performance** — unnecessary looping, extra copies, redundant calls, known slow browser APIs
 
-**Code clarity**
-- Are there comments that are outdated or misleading?
-- Are there any obvious simplifications (not refactors — just noise removal)?
+**TypeScript** — imprecise types, overuse of `any`/`unknown`, untyped third-party modules, irrelevant `tsconfig.json` options
 
----
+**Testing** — coverage gaps, tests that don't actually verify what they claim
 
-## How to respond
+**Runtime / tooling** — `node:*` APIs where Bun-native equivalents exist, `npm`/`yarn` artifacts in scripts, dependencies Bun now handles natively
 
-1. **Group findings by category.** Within each category, distinguish between:
-   - 🔴 Real issues (bugs, broken things) — implement the fix immediately
-   - 🟡 Improvements (best practices, clarity) — implement unless non-trivial
-   - 💡 Suggestions (optional tools, bigger changes) — describe but don't implement; let the user decide
+**Developer Experience** — missing or misleading `package.json` scripts, incomplete `.gitignore`/`.gitattributes`, missing docs or source comments
 
-2. **Be direct and brief.** One sentence per finding is usually enough. Don't pad.
+**Architecture / Technical Debt** — signs that complexity is accumulating: growing god-objects, framework or library choices that are becoming a liability, inconsistent patterns across similar code, coupling that makes changes harder than they should be, conventions the project has outgrown
 
-3. **Implement the 🔴 and 🟡 items** using file edits. Verify there are no new TypeScript errors afterward.
+## How to respond
 
-4. **Do not over-engineer.** A bug fix doesn't need surrounding code cleaned up. A simple improvement doesn't need extra configurability. Only change what needs changing.
+Group findings by category. Number each suggestion sequentially across all categories (1, 2, 3…) so the user can refer to them by number. For each finding:
+- 🔥 Actionable issue (bug, broken) — should be fixed soon
+- 👉 Improvement (best practice, clarity) — worth doing
+- 💡 Suggestion (optional, bigger change) — idea to track for future work