Migrate app-wide translations to Flutter l10n; keep protocol translations on CAWS

## Problem

App-side translations and protocol-side translations are loaded via the same `RPLocalizationsDelegate` stack:

```dart
RPLocalizationsDelegate(
loaders: [
AssetLocalizationLoader(), // app UI strings — assets/lang/{en,da,es}.json
bloc.localizationLoader, // protocol-specific strings — fetched from CAWS
],
);
```

The split itself is fine. The problem is the app-side keys: every `locale.translate("some.key")` call is a free-form string, and nothing checks that the key actually exists in `assets/lang/*.json`. When it doesn't, the literal key string renders in the UI. Recent occurrences: `pages.study.configuring`, `pages.devices.connection.settings`.

## Proposal

Migrate **app-wide** translations to [Flutter's official internationalization](https://docs.flutter.dev/ui/internationalization) (`flutter_localizations` + `gen_l10n`, `.arb` files). Keep **protocol-specific** translations on CAWS via the existing `bloc.localizationLoader`.

### Why

- `gen_l10n` generates an `AppLocalizations` class where every key is a typed method/getter. Renaming, finding usages, and catching missing keys all become compile-time.
- IDE support: autocomplete, jump-to-definition, refactor.
- Standard Flutter — easier onboarding for new contributors than the current custom `RPLocalizationsDelegate` stack for app strings.

### Scope

- App UI strings currently in `assets/lang/{en,da,es}.json` → migrate to `lib/l10n/app_{en,da,es}.arb`.
- Protocol-specific strings (study/task/consent/survey content) → unchanged, still loaded from CAWS via `bloc.localizationLoader`.
- Both sources coexist: widgets use `AppLocalizations.of(context).()` for app strings and `RPLocalizations.of(context).translate("...")` for protocol strings.

### Out of scope

- Replacing the CAWS protocol translation flow.
- Translation content review (just a mechanical migration of existing keys).

Start by inventorying app-side locale.translate calls and the existing assets/lang/{en,da,es}.json files. Read the RPLocalizationsDelegate setup and bloc.localizationLoader before creating lib/l10n/app_{en,da,es}.arb resources. Done means app strings use generated AppLocalizations while protocol-specific strings still come from CAWS through bloc.localizationLoader.

Written by the indexing model from the issue text.