285 routes in 21 feature files still inherit their tab title from the section above them

## What is wrong

285 routes across 21 feature route files still inherit their tab title from the section above them, so whole areas of the app share one title.

This is the follow-up I offered in [#339](https://github.com/apache/fineract-backoffice-ui/pull/339), which closed #250. That PR added `TranslatedTitleStrategy`, titled the 25 sections in `app.routes.ts`, and refined `groups.routes.ts` as the worked example. Angular's `buildTitle` walks up to the nearest titled ancestor, so every page already has a reasonable title and nothing is broken. But inheritance means every page under a section reads the same:

```
Products · Fineract <- product list
Products · Fineract <- create loan product
Products · Fineract <- edit charge
Products · Fineract <- fixed deposit product detail
```

65 routes under `products` resolve to that one title. 46 under `system`, 25 under `accounting`, 24 under `loans`.

## Business value

The same two reasons #250 gave, neither of which inheritance solves.

Back-office work is multi-tab work. Someone comparing two loan products, or checking an accounting rule while editing a charge, has a tab strip that says "Products, Products, Accounting, Products". The title is what makes a tab findable, and at section granularity it is not doing that. Browser history and bookmarks have the same problem: a bookmarked charge screen and a bookmarked product list are indistinguishable in the bookmark list.

And the non-visual case from #250 still stands. The document title is announced on navigation and is the main signal that the page changed in a single-page app. Announcing "Products" on every navigation within products is close to announcing nothing: the user learns that they are still where they were, which they knew.

## Finding them

Measured against `main` at 98770c4:

```
route files: 23
refined (any title:) 2 app.routes.ts, groups.routes.ts
UNREFINED 21
route entries total: 324
route entries in unrefined: 285
```

```bash
python3 - <<'PY'
import pathlib, re
PATH, TITLE = re.compile(r"\bpath\s*:"), re.compile(r"\btitle\s*:")
for p in sorted(pathlib.Path('src').rglob('*.routes.ts')):
s = p.read_text(errors='ignore')
n, t = len(PATH.findall(s)), len(TITLE.findall(s))
if n and not t:
print('%3d routes %s' % (n, p))
PY
```

Largest first: `products` (65), `system` (46), `accounting` (25), `loans` (24), `clients` (21), `organization` (19), `working-capital` (15), then `campaigns`, `security`, `spm`, `tellers` (7 each), `admin`, `centers`, `transfers` (6), `interop`, `settings` (5), `calendars`, `meetings` (4), `fintech`, `reporting`, `tasks` (2).

One correction to my own note in #339: I said 22 route files there. It is 21 against current `main`.

## Scope

Add `title:` to the routes in each file, as translation keys, the way `groups.routes.ts` does. `check-translations.mjs` already understands the route-title form, so a wrong key is a build failure rather than a silent fallback.

This is deliberately 21 independent pieces of work. No file depends on another, each is small, and each is reviewable on its own, which is what #250 asked for. That also makes it good first-issue material: anyone can take one file without coordinating.

So rather than assume it: **would you prefer one PR per feature area, a few grouped PRs, or one PR for all 21?** One PR touching 21 files is a large diff of very repetitive changes, and 21 PRs is a lot of review overhead in the other direction. My guess is that grouping by size, with the four big ones (`products`, `system`, `accounting`, `loans`) separate and the rest together, is the least review burden, but this is your call and I will follow whatever you prefer.

I am happy to leave some of these unclaimed for other contributors if you would rather use them that way. Say the word and I will take only the four large ones, or none.

Choose one unrefined feature route file from the listed areas and compare it with groups.routes.ts, using the route-title pattern shown there. Add translation-key titles to that file's routes, then run the provided route-count script and check-translations.mjs. Done means every route in the chosen file has an appropriate title and translation validation passes.

Written by the indexing model from the issue text.