feat(living-canvas): add multi-language support for Python, JavaScript, TypeScript, and Go

[cxxxr]

Description

Add tree-sitter based call graph providers for Python, JavaScript/TypeScript, and Go languages. This enables Living Canvas to visualize function call graphs for these languages in addition to Common Lisp.

New Features

• Provider Registry System: Language-agnostic provider management with priority-based selection
• Language Detection: Automatic language identification by major mode or file extension
• Python Provider: Function/method extraction and call relationship analysis via tree-sitter
• JavaScript/TypeScript Provider: Support for function declarations, arrow functions, and method definitions
• Go Provider: Support for functions and methods
• New Commands:
  • living-canvas-current-buffer - Multi-language support with auto-detection
  • living-canvas-diagnose - Troubleshoot provider status
  • living-canvas-reload-providers - Manual provider registration

Supported Languages

Language	File Extensions	Provider
Common Lisp	.lisp, .cl, .asd	micros (existing)
Python	.py, .pyw	tree-sitter
JavaScript	.js, .mjs, .cjs, .jsx	tree-sitter
TypeScript	.ts, .tsx, .mts, .cts	tree-sitter
Go	.go	tree-sitter

Future Work (separate PR)

• Project-wide analysis for tree-sitter languages (currently single-file only)

---

AI Usage Disclosure

Did you use LLMs/AI tools for this PR?

• No, this is 100% human-authored.
• Yes, AI-assisted (Human-led logic, AI-assisted implementation).
• Yes, AI-generated (Logic primarily derived from prompt/vibe).

Tooling Used: Claude Code (Claude Opus 4.5)

---

The "Human-in-the-Loop" Verification

1. Logic Walkthrough

The implementation follows a provider-based architecture for extensibility:

1. Provider Registry (call-graph/registry.lisp): A central registry that manages multiple language providers. Each provider has a priority, and the registry selects the highest-priority provider that supports a given language/source.

2. Language Detection (living-canvas/language-detection.lisp): Uses a two-tier detection strategy:

   • Primary: Check buffer's major mode (most reliable)
   • Fallback: Check file extension

3. Tree-sitter Providers (Python, JS, Go): Each provider:

   • Compiles tree-sitter queries for function definitions and calls
   • Extracts function/method nodes with source locations and argument lists
   • Builds call edges by finding enclosing functions for each call site
   • Registers itself on load and via *after-init-hook* (handles Nix build timing)

4. Command Flow: living-canvas-current-buffer → detect-language → find-provider → provider-analyze → render graph

Key design decisions:

• Providers register themselves to avoid central coordination
• *after-init-hook* solves Nix build issue where grammars aren't available at compile time
• Each provider is independent and can be loaded separately

2. Reviewer's Guide

High-risk areas:

• find-enclosing-function in each provider - uses return-from to correctly exit the function (not just the loop)
• Tree-sitter query syntax - queries must match the grammar's node types exactly
• Nix flake LD_LIBRARY_PATH - all grammar paths must be included for runtime loading

Suggested focus for reviewer:

• Verify tree-sitter queries work with real-world code (tested with sample files)
• Check that provider registration timing works in different startup scenarios
• Review CSS styles in buffer.lisp for new node types (class, method)

---

Related Issues

N/A (New feature based on spec in specs/001-multi-language-canvas/)

[code-contractor-app]

❌ Code Contractor Validation: FAILED

✓ Code Contractor Validation Result
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📊 Statistics:
  Files Changed:    33
  Lines Added:      6492
  Lines Deleted:    17
  Total Changed:    6509
  Delete Ratio:     0.00 (0%)

Status: FAILED ❌

🤖 AI Providers:
  - codex — model: (Codex default)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 Validation Rules:

❌ max_files_changed
❌ max_total_changed_lines
✅ max_delete_ratio
✅ defpackage_rule
✅ file_structure_rule
✅ loop_keywords_rule
✅ naming_conventions_rule
✅ docstring_rule
✅ internal_symbol_rule
✅ error_handling_rule
✅ frontend_interface_rule
❌ functional_style_rule
✅ dynamic_symbol_call_rule
✅ alexandria_usage_rule
✅ macro_style_rule

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠️ Violations Found (3):

[ERROR] max_files_changed
  Too many files changed: 33 > 10
  Limit: 10
  Actual: 33

[ERROR] max_total_changed_lines
  Too many lines changed: 6509 > 400
  Limit: 400
  Actual: 6509

[ERROR] functional_style_rule
  AI check failed: "functional_style_rule"
  ❌ Reason:
    Uses the dynamic global `*provider-registry*` as shared state instead of
    passing the registry explicitly via function arguments, violating the
    preference for explicit arguments over dynamic variables (and relying on
    `defvar`-based cross-function state).

Fix Suggestions

• functional_style_rule

• Fix for violation errors checked above

📚 About Code Contractor

Declarative Code Standards That Learn and Improve

Define domain-specific validation rules in YAML.
Your contracts document team knowledge and evolve into more accurate AI enforcement.

Want this for your repo?
→ Install Code Contractor

[code-contractor-app]

Code Contractor validation failed ❌ — see the sticky comment for full results.

[code-contractor-app]

Code Contractor: functional_style_rule

AI check failed: "functional_style_rule"

Reason:
Uses the dynamic global *provider-registry* as shared state instead of passing the registry explicitly via function arguments, violating the preference for explicit arguments over dynamic variables (and relying on defvar-based cross-function state).