feat: migrate documentation from Docusaurus to Astro Starlight

[niderhoff]

Changes

• Framework: Replace Docusaurus with Astro + Starlight theme.
• Components: Create pure Astro components (AvailableModels.astro, PlansPage.astro) replacing React+Scale components. Removes react dependency.
• Styling: Replace Docusaurus CSS (1,460 lines) with Starlight CSS variables + Telekom magenta branding (#e20074)
• CI/CD: Update GitHub Actions artifact path from build/ to dist/
• i18n: Use Starlight's built-in locale system (root = English, /de/ = German) replacing i18next
• German translations: Add full German translations for all 31 pages in src/content/docs/de/
• Cleanup: Remove Docusaurus theme overrides, Scale components, versioned docs, babel config

Why

• Faster builds (2.8s vs ~30s)
• Simpler dependency tree (3 deps vs 20+)
• Built-in search, i18n, and dark mode without plugins
• Server-rendered components instead of client-side React hydration

PR #63's content changes are now included in this PR

• "20+" → "30+" models
• "EU Hosted" badge → "T-Cloud: Germany Only"
• Updated description about T-Cloud vs hyperscaler data processing
• Added "Data Processing: Germany/EU" field to model cards
• All changes applied to both English and German versions

PR #63 can be closed once our migration PR is merged — its changes are fully incorporated.

[ashwinnair14]

Looks good.

• I see what we have an older docs on the prod docs website. https://docs.llmhub.t-systems.net/1.0.0/smartchat/smartchat-api-reference.
  Do u know if we can safely ignore this ?

• Remove the file MIGRATION_SPEC.md if u dont think we need it anymore.

• There is an issue in the code where in the plan section it does not show globe and it only shows the EU flag everywhere for even global as well.

const isEU = m.cloud === 'T-Cloud';                                                                              
  const dpLocation = isEU                                                                                          
    ? '<span class="fi fi-eu"></span> EU'                                                                          
    : '<span class="fi fi-eu"></span> EU & Worldwide'; 

• How does this logic particularly work in the Plans and pricing page? For example, for cloud 3.7 Sonnet data processing location is EU and worldwide but the server location is Europe. It feels a bit contradictory maybe by this we want to say that like the data processing can happen anywhere and the server location also can be anywhere or maybe I'm misunderstanding how this works. See image.
• The issue is in AvailableModels.astro — when the copy button is clicked, it replaces the button's textContent with a checkmark emoji, destroying the SVG icon inside. Notice how some of the models dont have the copy button once u click it.

The rest looks good to me 👍
CC should be able to fix the bugs I mentioned

[niderhoff]

@ashwinnair14

Regarding

How does this logic particularly work in the Plans and pricing page? For example, for cloud 3.7 Sonnet data processing location is EU and worldwide but the server location is Europe. It feels a bit contradictory maybe by this we want to say that like the data processing can happen anywhere and the server location also can be anywhere or maybe I'm misunderstanding how this works. See image.

We'd have to ask @ManvendraSinghJii for the intent here but reverse-engineering leads me to this:

Data Processing Location — derived purely from the hosting platform:
T-Cloud → "EU"
Azure/GCP → "EU & Worldwide"
(line 349 in PlansPage.astro: const isEU = m.cloud === 'T-Cloud')

Server Location — parsed from the deploymentRegion field in the pricing JSON (e.g., azure-europe → "Europe", otc-germany → "Germany")

So they're describing different things:

• Server Location = where the server physically sits (Europe, Germany, Sweden, etc.)
• Data Processing Location = a data sovereignty claim about where your data may be processed