Savings account servicing parity

Tracking issue for savings account servicing, which is now the largest functional gap in the
application.

## The gap

The savings account screen supports three commands — approve, activate and close. Fineract exposes
roughly twenty. Everything else an officer needs to do to a savings account has to be done outside
this application:

| Missing | Effect |
|---|---|
| `calculateInterest`, `postInterest` | Interest cannot be calculated or posted from here at all |
| `block` / `unblock` | An account cannot be frozen, e.g. on a fraud hold |
| `blockDebit` / `unblockDebit` | Withdrawals cannot be stopped while leaving deposits open |
| `blockCredit` / `unblockCredit` | The reverse — deposits stopped, withdrawals allowed |
| `applyAnnualFees` | Annual fees cannot be charged |
| `assignSavingsOfficer` | No officer can be assigned or changed |
| `reject`, `withdrawnByApplicant` | A pending application can only be approved, never declined |
| `holdAmount` / `releaseAmount` | Funds cannot be earmarked against a claim |
| GSIM (group savings) | Absent entirely — no group savings account can be managed |

This mirrors the loan servicing gap closed by the loan-servicing work, and the same approach
applies: probe each contract against a running Fineract, gate each action on the state that makes
it legal, and cover it at unit, mocked and backend level.

## Verified so far

Probed against a running Fineract on an active account. All of these are accepted on
`POST /savingsaccounts/{id}?command=`:

`calculateInterest`, `postInterest`, `block`, `unblock`, `blockDebit`, `unblockDebit`,
`blockCredit`, `unblockCredit`, `applyAnnualFees`, `assignSavingsOfficer`.

Notes that matter for the implementation:

- `block`, `blockDebit` and `blockCredit` require `reasonForBlock`.
- `unblockDebit` fails with *"debits.are.not.blocked"* when debits are not blocked, so the
reversals must be offered only in the state that permits them.
- `holdAmount` is **not** on the account endpoint — it lives on
`POST /savingsaccounts/{id}/transactions` and rejects a parameter named `amount`.
- `deposit` and `withdrawal` require `paymentTypeId`; the existing transaction form already sends
it.

## Sub-issues

Broken out below as each is implemented.

Start at the savings account screen and existing transaction form, then compare the listed commands with Fineract's savings-account and transaction endpoints. Implement the work as sub-issues, gating actions on legal account states and covering them at unit, mocked and backend level; done means the supported servicing actions work, including the transaction-specific hold endpoint and required paymentTypeId.

Written by the indexing model from the issue text.