RFC: add typescript-lsp plugin alongside pyright-lsp in .claude/settings.json

## Context

`.claude/settings.json` currently enables `pyright-lsp` for real-time TypeScript diagnostics during Claude Code editing sessions. This RFC asks whether we should also enable `typescript-lsp` (which runs `tsserver` — the same engine behind `tsc`).

Both are type-checkers for TypeScript. They have different implementations, different trade-offs, and occasionally produce different diagnostics for the same code.

## Current setup

| Component | Role |
|-----------|------|
| `tsc` (build step) | Compiles `src/` → `lib/`, emits `.d.ts`, uses `.tsbuildinfo` for incremental builds |
| `pyright-lsp` (Claude Code plugin) | Real-time type diagnostics during editing |
| Pre-commit hooks | Run `tsc --noEmit` + ESLint before push |

## Arguments for adding typescript-lsp

1. **Module resolution fidelity** — `tsserver` uses the identical resolver as `tsc`. In a `"moduleResolution": "nodenext"` project with CDK alpha packages (`@aws-cdk/aws-bedrock-agentcore-alpha`), conditional exports, and `resolveJsonModule`, there are known divergences where Pyright and `tsc` disagree on import validity. `tsserver` catches what `tsc` would reject.

2. **jsii-generated types** — CDK constructs have `.jsii` assembly metadata. `tsc`/`tsserver` respects these for overload resolution and deprecation; Pyright doesn't read `.jsii` manifests.

3. **Incremental state parity** — `tsserver` shares the same `.tsbuildinfo` as the build, so its diagnostics reflect stale cross-file references after renames. Pyright re-analyzes from scratch and may not catch artifacts that cause real build failures.

4. **Two independent oracles** — When two type-checkers disagree, that often signals a subtle real issue (unsound assertion, conditional type edge case). Seeing both perspectives before committing reduces "passes locally, fails CI" roundtrips.

5. **Rename/refactor accuracy** — `tsserver` rename follows the compiler's semantic graph exactly, including re-exports and namespace-qualified references in CDK construct trees.

6. **Reduces need for local `tsc --noEmit`** — Pre-push hooks run `tsc` which triggers CDK synth artifacts that fill `/tmp` on this system. Incremental `tsserver` diagnostics during editing could catch the same errors without a full compile pass.

## Arguments against adding typescript-lsp

1. **Diagnostic noise from disagreements** — When Pyright says "clean" and `tsserver` flags something (or vice versa), Claude Code must decide which to trust. Divergent diagnostics may cause unnecessary edits or confusion.

2. **Resource cost** — Running two full TypeScript analysis engines concurrently doubles memory and CPU for type-checking. On resource-constrained dev instances this may degrade responsiveness.

3. **Pyright is already sufficient** — Pyright covers `strict: true`, `strictNullChecks`, `noImplicitAny`, and all the flags this project uses. The build step (`tsc`) catches anything Pyright misses before code reaches CI.

4. **Maintenance burden** — Two LSPs may surface conflicting quick-fixes or code actions, requiring contributors to learn which to follow.

5. **The actual divergences are rare** — In practice, Pyright and `tsc` agree on 99%+ of diagnostics for standard CDK code. The edge cases (alpha packages, `.jsii`, conditional exports) may not justify the overhead.

## Questions for the team

- Have we experienced CI failures that `tsserver` diagnostics would have caught but Pyright missed?
- Is the `/tmp` fill issue from pre-push hooks a strong enough motivator to shift type-checking entirely to LSP-time?
- Would we enable both LSPs or replace Pyright with typescript-lsp?
- Are there performance concerns on the dev instances we use?

## References

- Current config: `.claude/settings.json`
- TSConfig: `cdk/tsconfig.json` (`module: "NodeNext"`, `strict: true`, `incremental: true`)
- Related: `/tmp` fill issue from CDK synth during hooks

Lies .claude/settings.json und cdk/tsconfig.json zuerst und vergleiche dann die aktuelle pyright-lsp-Konfiguration mit der dokumentierten TypeScript- und Build-Konfiguration. Prüfe die Antworten des Teams zu Abweichungen bei Diagnosen, Ressourcenaufwand und Hook-Verhalten; abgeschlossen ist die Aufgabe, wenn klar entschieden wurde, ob das Plugin hinzugefügt oder ersetzt werden soll, und die Konfiguration nur aktualisiert wird, wenn dies genehmigt wurde.

Vom Indexierungsmodell aus dem Issue-Text verfasst.