feat: scaffold SvelteKit project with Tailwind, TypeScript, ESLint, Prettier

Initialize the llm-multiverse-ui project with:
- SvelteKit + Svelte 5 (runes mode enabled)
- Tailwind CSS v4 via @tailwindcss/vite plugin
- TypeScript strict mode
- ESLint 9 flat config with svelte and typescript-eslint plugins
- Prettier with svelte plugin
- Directory structure: src/lib/components/, src/lib/services/
- All required scripts: dev, build, preview, lint, format, check

Closes #1

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

.claude/commands/code-review.md

@@ -26,6 +26,7 @@ git diff main --name-only
 ```
 
 Read every changed file in full. Also read the diff for context on what changed:
+
 ```bash
 git diff main
 ```
@@ -35,23 +36,27 @@ git diff main
 Evaluate each changed file against these dimensions:
 
 **Correctness:**
+
 - Does the code do what the issue and plan require?
 - Are edge cases handled?
 - Are error conditions properly managed?
 
 **Security:**
+
 - No XSS vulnerabilities
 - No credentials or API keys in client-side code
 - No sensitive data stored insecurely
 - Proper input sanitization
 
 **Architecture:**
+
 - Component boundaries respected
 - State management follows project patterns
 - API communication uses established patterns
 - Proper separation of concerns
 
 **Code Quality:**
+
 - Idiomatic TypeScript/framework patterns
 - Consistent error handling
 - Meaningful variable and function names
@@ -59,17 +64,20 @@ Evaluate each changed file against these dimensions:
 - No `any` types without justification
 
 **Testing:**
+
 - Sufficient test coverage
 - Meaningful test cases (not just happy path)
 - Component tests for UI behavior
 - Proper mocking of external dependencies
 
 **Accessibility:**
+
 - Semantic HTML elements used
 - ARIA attributes where needed
 - Keyboard navigation support
 
 **Performance:**
+
 - No unnecessary re-renders
 - Proper memoization where beneficial
 - No memory leaks
@@ -78,12 +86,12 @@ Evaluate each changed file against these dimensions:
 
 Each finding MUST be categorized:
 
-| Severity | Description | Blocks Merge? |
-|---|---|---|
-| **Critical** | Security vulnerability, data loss risk, major architectural violation | Yes |
-| **Major** | Bug, missing error handling, test gap, significant design issue | Yes |
-| **Minor** | Style issue, naming improvement, small optimization, documentation gap | No |
-| **Suggestion** | Optional improvement, alternative approach worth considering | No |
+| Severity       | Description                                                            | Blocks Merge? |
+| -------------- | ---------------------------------------------------------------------- | ------------- |
+| **Critical**   | Security vulnerability, data loss risk, major architectural violation  | Yes           |
+| **Major**      | Bug, missing error handling, test gap, significant design issue        | Yes           |
+| **Minor**      | Style issue, naming improvement, small optimization, documentation gap | No            |
+| **Suggestion** | Optional improvement, alternative approach worth considering           | No            |
 
 ### 5. Produce Review Report
 
@@ -117,6 +125,7 @@ Request Changes: one or more critical/major findings
 ### 6. Handle Minor Findings
 
 If the verdict is **APPROVE** but there are minor findings:
+
 1. Create a single Gitea issue titled: "Tech debt: minor findings from issue #$ARGUMENTS review"
 2. List all minor findings in the issue body as checklist items
 3. Apply labels: `type:refactor`, `priority:low`, `cat:tech-debt`
@@ -125,6 +134,7 @@ If the verdict is **APPROVE** but there are minor findings:
 ### 7. Post Review to PR
 
 If a pull request exists for the feature branch:
+
 - Add a review comment via `mcp__gitea__pull_request_review_write`
 - If APPROVE: approve the PR
 - If REQUEST_CHANGES: request changes with the critical/major findings listed