Accounting: GL account mappings for fixed and recurring deposit products — and stop the edit path destroying them

Part of #288. Depends on #289 — wait for it to merge.

## Business value

Two problems here, and the second is a live data-loss bug that this sub-task should fix while it is in the file.

**1. No accounting.** `fixed-deposit-product-form.component.ts:254,285` and `recurring-deposit-product-form.component.ts:245,277` both hardcode `accountingRule: 1`. Term deposits are a liability the institution owes and interest on them is an expense; neither reaches the ledger.

**2. The edit path is destructive.** `fixed-deposit-product-form.component.ts:276-311` — `loadProductData()` repopulates only about eight fields and hardcodes a fallback deposit amount along with `accountingRule: 1`. Submit then PUTs that, together with a **fabricated** interest-rate chart. So opening an existing deposit product and saving it silently overwrites its deposit amount, its accounting rule and its entire rate chart. The recurring form does the same at `:289-296`.

That second one is worse than the missing feature. A user who opens a product to check a value and clicks Save has changed the product's economics without being told.

## What to build

**First, fix the load path.** It must populate every field the form submits. If a field cannot be loaded it must not be submitted — a form that PUTs a fabricated value for something it did not read is worse than one that omits it.

**Then add the mappings**, using the components from #289. Term deposits use the savings mapping set as their base; confirm the exact slots against the fixed-deposit and recurring-deposit product template responses on a live instance (`npm run e2e:stack`).

Consider whether the two forms should share their accounting section. They are near-identical and drift is already visible between them.

## Testing

The bug fix needs its own test, and it is the important one:

```ts
it('preserves every field it does not change when editing', () => {
// load a product with a deposit amount, an accounting rule and a rate chart
// change one unrelated field
// assert the PUT body still carries all three, unmodified
});
```

That spec fails today. Write it first.

Then the usual: submitted body carries the mapping keys; loading a configured product populates them; a mocked e2e asserting the intercepted `PUT`.

## Scope

In scope: the load path for both deposit product forms, and their GL mappings.

Out of scope: the deposit *account* screens, which are broken separately — see #279 and the term-deposit servicing epic. Interest-rate chart editing as a feature; here the rate chart only has to survive an edit, not become editable.

## Getting started

- `src/app/features/products/fixed-deposits/fixed-deposit-product-form.component.ts`
- `src/app/features/products/recurring-deposits/recurring-deposit-product-form.component.ts`
- Shared components from #289
- `npm test`, `npm run lint:prune`, `npm run i18n:check`, `npm run build`

Start with fixed-deposit-product-form.component.ts and recurring-deposit-product-form.component.ts, especially the listed load and submit ranges, and write the specified preservation regression test first. Use the shared accounting components from #289 and the live product template responses from npm run e2e:stack to verify mapping slots; done means unchanged fields and rate charts survive edits and mapping keys are submitted and loaded.

Written by the indexing model from the issue text.