[EPIC] Term deposit account servicing — a fixed or recurring deposit account cannot be operated once opened

## Business value

Fixed and recurring deposit accounts can be created and approved from a list row, and that is where it ends.

`src/app/features/products/deposit-account-view.component.ts:367-375` — the entire action menu on the shared deposit account view is Deposit and Withdraw, and both navigate to routes that do not exist:

```ts
onDeposit(): void {
this.router.navigate([`/products/recurring-deposits/${this.accountId}/transactions/deposit`]);
}
```

The only transaction routes declared in `products.routes.ts` are `fixed-deposits/:accountId/transactions` (`:345`) and `recurring-deposits/:accountId/transactions/create` (`:352`). Neither target exists, and `onDeposit` ignores `isRD` so a fixed deposit builds a recurring-deposit URL.

Missing entirely: **activate, reject, undo approval, withdraw by client, close, premature close, interest posting**. There is no charges tab, no transactions tab with a correction path, and no way to see the maturity position.

So a member opens a term deposit, the branch approves it, and then nobody can activate it — which means it never starts earning, never matures, and never pays out. Two entire product families are non-operational past creation.

Recurring deposits in particular are a staple group-savings product; a branch that cannot record instalments against one cannot offer it.

## Related work already filed

- **#279** — the two dead navigation targets and the `isRD` bug. Small, self-contained, good first issue.
- **#278** — the recurring-deposit transaction form omits the `command` query parameter the platform requires, so every submission returns 400. Confirmed by probe against a live instance.

Those two are the minimum to make the existing screens honest. **This epic is the work beyond them.** Neither is a prerequisite for the sub-tasks here, but landing them first avoids building on top of a broken form.

## Sub-tasks

Split so each is independently shippable. The lifecycle actions come first — without activation nothing else in the epic is reachable on a real account.

## Scope

In scope: the shared deposit account view, its lifecycle actions, transactions, charges, and the fixed-deposit transaction form.

Out of scope: deposit *product* configuration, including the destructive edit path — that is #292. Savings accounts, which have their own servicing gaps (#197).

## Getting started

- Shared view: `src/app/features/products/deposit-account-view.component.ts`
- Routes: `src/app/features/products/products.routes.ts`
- The savings account view (`savings-account-view.component.ts`) is the closest working model in the codebase — it has the command dispatch, block reasons and status gating patterns to copy.
- Every command payload must be confirmed against a live instance. `npm run e2e:stack` brings one up. Commands in this API are routinely asymmetric about `locale` and `dateFormat`, and a 400 usually enumerates the accepted values in its `args` array.

## Verification

Open a recurring deposit account through the UI, approve it, activate it, record two instalments, and confirm the transactions tab shows both with a running balance. That flow — not the menu rendering — is the definition of done.

Start with src/app/features/products/deposit-account-view.component.ts and the transaction entries in src/app/features/products/products.routes.ts, then compare the command dispatch, block reasons, and status gating in savings-account-view.component.ts. Run npm run e2e:stack to confirm command payloads against a live instance; done means the recurring-deposit flow can be opened, approved, activated, receive two instalments, and show both transactions with a running balance.

Written by the indexing model from the issue text.