v0.5.0 — per-stack capability guard

Each ABAP handler now declares the object types it can translate (an editable allow-list), and the MCP server enforces it up-front — instead of surfacing a raw error after the call.

Highlights

• ABAP capabilities action (both handlers) returns { list_texts: [target_type…], set_translation: [target_type…] }. One object type per line → removing a possibility is a one-line edit. Cloud omits text_pool from list_texts only (writable but not listable with the released APIs).
• Capabilities differ by stack (public cloud / BTP ABAP Environment vs on-premise / private cloud) and by system release — a future per-release class (e.g. zcl_i18n_service_2022 / _2025) just declares its own list, no server change.
• LISA probes capabilities once (cached) and rejects an unsupported target_type up-front (isTargetTypeSupported). Older handlers without the action degrade gracefully to permissive — the CLOUD_UNSUPPORTED backstop still fires.
• N2: CLOUD_UNSUPPORTED mapped to a clear message; stack/release differences documented in the target_type tool description.

Validation / caveats

build / lint / 30 tests green; deployed to BTP DEV + SANDBOX (permissive). ⚠️ The ABAP changes need import into the target system(s) and live testing — they could not be compiled in this environment; until re-imported the server stays permissive.

🤖 Generated with Claude Code