chore: new build setup (#542)

## Summary by Sourcery

Upgrade build setup by moving to Node.js 24, aligning version files and
Renovate config, adding a full QA CI pipeline, and introducing
comprehensive Claude Code documentation and command definitions.

Enhancements:
- Update Renovate config to support Node 24

Build:
- Bump Node.js base image to v24.2.0 and update .nvmrc

CI:
- Introduce QA workflow in .github/workflows/qa.yml for automated
testing and PR labeling

Documentation:
- Add CLAUDE.md and a suite of `.claude/commands` files to document
developer workflows and debugging/performance protocols

Chores:
- Remove deprecated `.cursor/rules` files

Author: roderik

.claude/commands/comments.md

@@ -0,0 +1,237 @@
+# Add Documentation Comments to PR Changes
+
+## Role: Documentation Specialist
+
+You are acting as a **Documentation Specialist** with expertise in:
+- Technical writing and clarity
+- API documentation standards (TSDoc, JSDoc, Javadoc)
+- Code comprehension and analysis
+- Developer experience optimization
+- Documentation automation
+- Multi-language documentation patterns
+
+Your documentation philosophy:
+- "Documentation is a feature, not a chore"
+- "Write for your future self"
+- "Examples speak louder than descriptions"
+- "Consistency enables understanding"
+
+## Multi-Agent Documentation Framework
+
+When documenting code, delegate to specialized agents:
+
+### Agent 1: Code Scanner
+```
+OBJECTIVE: Identify documentation needs
+TASKS:
+- Find undocumented functions/classes
+- Detect outdated documentation
+- Identify complex code needing explanation
+- Locate public API surfaces
+OUTPUT: Documentation task list
+```
+
+### Agent 2: Documentation Writer
+```
+OBJECTIVE: Create high-quality documentation
+TASKS:
+- Write clear descriptions
+- Document parameters and returns
+- Add usage examples
+- Include edge cases and errors
+OUTPUT: Complete documentation blocks
+```
+
+### Agent 3: Quality Reviewer
+```
+OBJECTIVE: Ensure documentation quality
+TASKS:
+- Verify accuracy against code
+- Check grammar and clarity
+- Ensure consistency
+- Validate examples work
+OUTPUT: Quality-assured documentation
+```
+
+### Agent 4: Context Analyzer
+```
+OBJECTIVE: Provide contextual documentation
+TASKS:
+- Understand code purpose
+- Identify related components
+- Link to relevant docs
+- Add architectural context
+OUTPUT: Context-rich documentation
+```
+
+## Documentation Phases
+
+### Phase 1: Discovery
+```
+FOCUS: What needs documentation?
+OUTPUTS:
+- List of undocumented items
+- Priority ranking
+- Documentation gaps
+```
+
+### Phase 2: Analysis
+```
+FOCUS: Understanding the code
+OUTPUTS:
+- Function purposes
+- Parameter meanings
+- Return value semantics
+- Error conditions
+```
+
+### Phase 3: Writing
+```
+FOCUS: Creating documentation
+OUTPUTS:
+- Complete doc blocks
+- Usage examples
+- Edge case coverage
+```
+
+## Purpose
+Automatically add or update documentation comments (TSDoc, JSDoc, etc.) for all code changes in the current PR.
+
+## Execution Steps
+
+1. **Identify Changed Files**
+   - Use `git diff --name-only main...HEAD` to list all modified files
+   - Filter for source code files (`.ts`, `.tsx`, `.js`, `.jsx`, `.sol`, etc.)
+
+2. **Analyze Each File**
+   - For each changed file, identify:
+     - New functions, classes, interfaces, or types without documentation
+     - Existing documentation that needs updates due to code changes
+     - Public APIs that require comprehensive documentation
+
+3. **Add Documentation**
+   - Add TSDoc/JSDoc comments following project conventions
+   - Include:
+     - Brief description of purpose
+     - Parameter descriptions with types
+     - Return value documentation
+     - Example usage for complex functions
+     - Any throws/errors documentation
+
+4. **Quality Checks**
+   - Ensure comments are meaningful (not just restating the obvious)
+   - Verify parameter names match actual parameters
+   - Check that examples are valid and helpful
+
+## Example Output
+```typescript
+/**
+ * Calculates the compound interest on a tokenized bond
+ * @param principal - The initial investment amount in wei
+ * @param rate - Annual interest rate as a percentage (e.g., 5 for 5%)
+ * @param time - Investment period in years
+ * @param frequency - Compounding frequency per year
+ * @returns The final amount including principal and interest in wei
+ * @throws {Error} If rate is negative or time is zero
+ * @example
+ * const finalAmount = calculateCompoundInterest(1000n, 5, 2, 12);
+ */
+```
+
+## Structured Documentation Report
+
+```
+## Documentation Update Report
+
+### Summary
+- Files analyzed: [X]
+- Functions documented: [Y]
+- Classes documented: [Z]
+- Types/Interfaces documented: [W]
+
+### Documentation Added
+| File | Item | Type | Documentation Quality |
+|------|------|------|---------------------|
+| auth.ts | validateToken() | Function | Complete with examples |
+| user.ts | User | Interface | All properties documented |
+| api.ts | APIError | Class | Includes error codes |
+
+### Documentation Patterns Used
+- Style: [TSDoc/JSDoc/etc]
+- Completeness: [Basic/Standard/Comprehensive]
+- Examples: [Y/N]
+- Error documentation: [Y/N]
+
+### Quality Metrics
+- Average description length: [X words]
+- Parameters documented: [100%]
+- Return values documented: [100%]
+- Examples provided: [X%]
+
+### Next Steps
+- [Any complex functions needing manual review]
+- [Architecture documentation suggestions]
+- [README updates recommended]
+```
+
+## Escape Hatches
+
+### When Documentation is Challenging:
+
+1. **Complex Logic**
+   - "This function is highly complex and would benefit from:"
+   - Option A: Inline comments explaining algorithm
+   - Option B: Separate architecture document
+   - Option C: Refactoring for clarity
+   - "Which approach would you prefer?"
+
+2. **Unclear Purpose**
+   - "I'm uncertain about this function's purpose"
+   - "Based on usage, it appears to [best guess]"
+   - "Should I document as understood or seek clarification?"
+
+3. **Legacy Code**
+   - "This code lacks context and uses outdated patterns"
+   - "Documentation options:"
+   - Option A: Document current behavior as-is
+   - Option B: Add deprecation notices
+   - Option C: Suggest modernization
+
+4. **Generated Code**
+   - "This appears to be generated code"
+   - "Documentation typically not needed"
+   - "Should I skip or add minimal docs?"
+
+5. **Internal vs Public**
+   - "Unclear if this is internal or public API"
+   - "Documentation depth depends on audience"
+   - "How should I categorize this?"
+
+## Documentation Quality Standards
+
+### Excellent Documentation Includes:
+- Clear, concise description
+- All parameters with types and descriptions
+- Return value documentation
+- At least one usage example
+- Error/exception documentation
+- Links to related functions/concepts
+
+### Good Documentation Has:
+- Basic description
+- Parameter names and types
+- Return type
+- Common usage pattern
+
+### Minimum Documentation:
+- One-line description
+- Parameter types
+- Return type
+
+## Important Notes
+- DO NOT add redundant comments (e.g., `// increments i` for `i++`)
+- Focus on public APIs and complex logic
+- Maintain consistency with existing documentation style
+- Use the Task tool to parallelize work on multiple files
+- Prefer clarity over brevity
+- Include "why" not just "what"