31 hardcoded English strings on list screens ignore the language setting

## Business value

The application ships three locales and offers a language switcher, so a user who selects Hindi expects the interface to be in Hindi. On seventeen list screens it partly is not: the page heading, the create button, or an action tooltip stays in English regardless of the language chosen.

The effect is worse than an untranslated string usually is, because of *which* strings these are. They are the page heading and the primary action — the two pieces of text a user reads to work out where they are and what they can do. A screen whose heading is `Chart of Accounts` and whose button is `Add Ledger Account`, sitting inside an otherwise translated shell, reads as half-broken.

These also escape the normal safety net. Everything else goes through a translation key, so a missing translation shows up as a visible key like `GROUPS.CREATE_GROUP` and diagnoses itself. A hardcoded English string looks correct in every locale and is only findable by grep.

## Reproducing it

```
grep -rn 'title="[A-Z][a-z][^"]*"\|createButtonLabel="[A-Z][a-z][^"]*"\|searchPlaceholder="[A-Z][a-z][^"]*"' \
src/app --include=*.ts | grep -v spec
```

31 sites across 17 files. By feature: accounting 11, products 5, loans 4, tasks 3, fintech 3, centers 2, and one each in security, clients and campaigns.

A sample:

```ts
// src/app/features/accounting/chart-of-accounts.component.ts:45
title="Chart of Accounts"
createButtonLabel="Add Ledger Account"

// src/app/features/loans/collateral/collateral-list.component.ts:64
title="Edit Collateral"
```

Switch the language to Hindi or Korean and those three strings stay in English.

## Describing the change

Replace each literal with a translation key, and add the key to `src/assets/i18n/en.json` if it is not already there.

`app-data-table` translates `title`, `createButtonLabel` and `searchPlaceholder` for you, so those are a straight substitution:

```ts
// before
title="Chart of Accounts"
createButtonLabel="Add Ledger Account"

// after
title="ACCOUNTING.CHART_OF_ACCOUNTS"
createButtonLabel="ACCOUNTING.ADD_LEDGER_ACCOUNT"
```

The `title=` attributes on `ion-button` are native tooltips rather than a data-table input, so they need the pipe and a binding:

```ts
// before

// after

```

Check `en.json` before inventing a key — most of these screens already have a section with a suitable one, and reusing it is better than adding a near-duplicate.

**This is naturally one pull request per feature directory**, and a first contribution should take one feature rather than all seventeen files. Accounting is the largest at 11 sites; `centers`, `security`, `clients` and `campaigns` are one or two each and are the gentlest starting point.

## Scope

In scope: the 31 sites above, plus any `en.json` keys they need.

Out of scope: translating the new keys into `hi.json` and `ko.json` (those catalogues are separately incomplete and tracked elsewhere), and the untranslated strings inside component bodies rather than these three attributes.

## Getting started

- `DOCS/ADAPTERS.md` explains `appTranslate`, which is how this codebase reaches translation — note it is `| appTranslate`, not `| translate`.
- Keys live in `src/assets/i18n/en.json`.
- Verify by switching the language in the app and confirming the string changes; a key with no entry renders as the key itself, which is the intended failure mode.
- `npm run build` and `npm run lint` must pass.

Choose one feature directory and inspect the listed hardcoded title, createButtonLabel, searchPlaceholder, or ion-button title sites, starting with the sample component and DOCS/ADAPTERS.md. Check src/assets/i18n/en.json before selecting keys, then verify the language switch changes the strings and run npm run build and npm run lint.

Written by the indexing model from the issue text.