Feature Request: Language-specific reviewers (/review-typescript, /review-swift, /review-python, /review-kotlin)

## Summary
The existing /review skill performs a strong generic "staff engineer" code review,
but it applies the same lens regardless of language. TypeScript, Swift, Python, and
Kotlin each have distinct failure modes, type system behaviors, and community
standards that a generalist reviewer consistently misses. Language-specific
reviewers would dramatically increase review quality by applying the right checks
for the language actually being reviewed.

## Current State
/review runs a single generalist pass: auto-fixes, completeness checks, and
staff-engineer-level feedback. This works well for general logic and architecture
issues but misses:

- Language-specific type system misuse (TypeScript's any, Swift's force-unwrap !,
Python's mutable default arguments)
- Idiomatic patterns each language community considers non-negotiable
- Compiler and runtime behaviors unique to that language (Swift ARC memory
management, TypeScript strict mode gaps, Python GIL implications)
- Ecosystem-specific anti-patterns (React hook rules in TypeScript, @MainActor
enforcement in Swift, async/await misuse per language)

## Proposed Skills

/review-typescript
Focus areas:
- strict mode compliance and tsconfig hygiene
- Improper use of any, as casting, and ! non-null assertions
- React hook dependency array correctness
- Missing discriminated union exhaustiveness checks
- Type inference vs explicit annotation judgment
- Module boundary and barrel file patterns
- Floating Promise detection and error handling gaps

/review-swift
Focus areas:
- Force-unwrap ! and unsafe try! usage
- @MainActor and concurrency isolation correctness
- ARC retain cycle detection in closures
- SwiftUI @State/@Binding/@ObservableObject misuse
- Sendable and structured concurrency correctness
- Protocol conformance and associated type patterns
- iOS Human Interface Guidelines violations in UI code

/review-python
Focus areas:
- Mutable default argument anti-pattern
- Type hint completeness and mypy compatibility
- Exception handling specificity (bare except: clauses)
- Generator vs list comprehension judgment
- async/await correctness and event loop misuse
- Import structure and circular dependency risk

/review-kotlin
Focus areas:
- Null safety: !! operator usage and safe call chain patterns
- Coroutine scope and dispatcher correctness
- Data class vs sealed class usage decisions
- Extension function overuse
- companion object vs top-level function judgment
- Jetpack Compose recomposition and remember correctness

## Implementation Suggestion
These could be implemented as thin wrappers over /review that inject a
language-specific ruleset at invocation rather than entirely separate skill
definitions. This keeps maintenance cost low while delivering meaningfully
different review output. They could also delegate via the existing /pair-agent
multi-agent coordination mechanism.

## Expected Impact
A developer working in a typed language gets the most value from a reviewer who
knows the type system deeply. Generic reviews routinely miss Swift memory bugs
and TypeScript type-safety gaps that a language-aware reviewer catches
immediately. For gstack's target user — a solo developer moving at team speed —
catching these issues before /ship runs is exactly where the ROI is highest.