feat: Add i18n support and adapt for Headscale v0.28 (with ACL management)

[serein-213]

Description

This PR integrates Internationalization (i18n) support and updates the admin panel to fully support Headscale v0.28.0 features, including a new ACL management interface.

I have organized the changes into two clean commits for easier review:

1. i18n: Infrastructure setup and translation extraction.
2. Features: Headscale v0.28 adaption and ACL UI implementation.

Key Changes

🌐 Internationalization (i18n)

• Added svelte-i18n to handle localization.
• Included English (en) and Chinese Simplified (zh) locales.
• Extracted hardcoded UI strings to locale files.

🚀 Headscale v0.28 Features

• New ACL Management UI: Added capability to manage Policies, SSH Rules, Groups, and Tag Owners.
• API Updates: Aligned API services with Headscale v0.27/v0.28 response structures.
• State Management: Refactored core state using States.svelte.ts for improved reactivity.

Motivation

To make the tool accessible to non-English speakers and to expose the powerful ACL configuration features available in newer Headscale versions.

Testing

• Verified en/zh language switching.
• Tested CRUD operations for ACL Policies and Groups against Headscale v0.28.

[ch604]

many of the ui features reference cards.* for which there is no match in the english localization file (though they are in general). how are new localizations generated or updated, and how are the json keys kept in order?

[serein-213]

many of the ui features reference cards.* for which there is no match in the english localization file (though they are in general). how are new localizations generated or updated, and how are the json keys kept in order?

Good catch. At the moment, localizations in this project are maintained manually rather than generated automatically. We load the locale files directly through svelte-i18n, and there is currently no extraction/sync script in the project to generate missing keys or enforce key ordering.

So in practice, new localization entries are added by hand to src/lib/locales/en.json and src/lib/locales/zh.json, and the JSON key order is also maintained manually to match the existing structure.

In this PR, I missed syncing several cards.* entries into the English locale file. Those keys do exist in zh.json, and some of them are already referenced by the UI, but they were not added to en.json. I’ll follow up by syncing the missing English keys and aligning the ordering with the existing locale structure.

Longer term, I agree it would be better to add a small validation or sync step so missing localization keys and ordering drift can be caught automatically.

[ch604]

awesome, just tested 07cf626 and locale is now looking great! long term, it would be no small feat to add community translation through something like tolgee. now, just waiting on @GoodiesHQ ...