[EPIC] Product accounting configuration — every product created through this UI is unaccounted

## Business value

Every product form in the app hardcodes `accountingRule: 1` — the platform's value for **NONE**. Nine sites, all five product families:

```
products/loan-product-form.component.ts:1350
products/savings-product-form.component.ts:263, 291
products/fixed-deposits/fixed-deposit-product-form.component.ts:254, 285
products/recurring-deposits/recurring-deposit-product-form.component.ts:245, 277
products/shares/share-product-form.component.ts:282, 309
```

And there is not one GL-mapping field anywhere in the application:

```
grep -rn "fundSourceAccountId\|loanPortfolioAccountId\|interestOnLoanAccountId\|savingsReferenceAccountId" \
src/app/features --include=*.ts
# no results
```

So no product created here ever posts a journal entry. A loan is disbursed and the general ledger does not move. Interest accrues and nothing reaches an income account. A fee is collected and it lands nowhere.

**This is what makes the rest of the accounting module inert.** The chart of accounts, accounting rules, financial activity mappings, accounting closures and provisioning screens are all built and all working — and they have nothing to attach to, because no product references a GL account. An institution cannot produce a trial balance, cannot close a period, and cannot reconcile. For a regulated lender that is not a missing feature, it is a reason not to deploy.

It is also the cheapest large win available: the platform accepts the mappings on the same `POST`/`PUT` the forms already send. Nothing new needs designing on the backend.

## What the platform expects

`accountingRule` takes four values: `1` NONE, `2` CASH, `3` ACCRUAL_PERIODIC, `4` ACCRUAL_UPFRONT. Everything else follows from which is chosen — a cash-based product needs a small set of mappings, an accrual product needs receivable accounts as well.

Each product family has its own mapping set, and the product template endpoint returns the GL accounts eligible for each slot. The forms already call those template endpoints for other option lists, so the data is in reach.

## Sub-tasks

Each sub-issue is independently shippable and independently useful — a loan product with correct accounting is worth having before savings is done. Take them in roughly this order; the first establishes the shared pieces every later one reuses.

Sequencing note: sub-task 1 builds the shared accounting section and the accounting-rule selector. **Do not start 2–5 until it has merged**, or five PRs will each invent their own version of the same component.

## Scope

In scope: the accounting rule selector, the GL mapping fields per product family, advanced mappings, and reading existing mappings back when editing a product.

Out of scope: the chart of accounts, accounting rules, and financial activity mapping screens — all already exist and work. Nothing about journal entry viewing or reversal (tracked separately). No change to the generated API client.

## Getting started

- Product forms: `src/app/features/products/`
- Template endpoints already called by those forms for currency and charge options
- The accounting screens this unblocks: `src/app/features/accounting/`
- `npm test`, `npm run lint:prune`, `npm run i18n:check` and `npm run build` must pass on every PR.

## Verification

Configure a loan product with cash accounting, disburse a loan against it, then open the journal entries screen and confirm the disbursement produced a balanced entry against the mapped fund source and portfolio accounts. That end-to-end check is the definition of done for this epic — not the forms rendering.

Start in src/app/features/products/ and review the existing template endpoint calls used by the product forms. Begin with sub-task 1: establish the shared accounting section and accounting-rule selector before implementing product-family mappings. Verify with the listed npm checks, then configure a cash-accounting loan, disburse it, and confirm a balanced journal entry using the mapped accounts.

Written by the indexing model from the issue text.