[EPIC] Reporting engine — one renderer, three hardcoded parameters, and reports that silently return wrong rows

## Business value

Reports are how everyone outside the branch sees the portfolio — the board, the regulator, the funder, the auditor. The reporting screen currently supports one output format and three fixed parameters.

`src/app/features/reporting/run-report.component.ts`:

```ts
:219 reportType = '';
:250 this.reportType = params.get('type') || ''; // assigned, then never read again
:271 'CSV', // outputType — hardcoded
:308 'HTML', // outputType — hardcoded
:318 const columnHeaders = (result['columnHeaders'] as ...) || [];
```

Three consequences, and the middle one is the dangerous one.

**1. One renderer.** Only tabular HTML is rendered. `reportType` is read from the query string and discarded, so a chart report, a Pentaho report and a table report all take the same path.

**2. Parameters are fixed to Office, From Date and To Date, and the parameter-template endpoint is never called.** Any report whose definition expects a loan officer, currency, product, fund, PAR type or obligation-date type gets those parameters left empty — and the platform runs the report anyway, returning **rows for the wrong scope with no error at all**. A user reads a portfolio-at-risk figure that omits a filter they think they applied. That is worse than the report failing.

**3. No chart, Pentaho or BIRT output**, so member statements, receipts and certificates cannot be produced at all.

And per **B6** in the gap survey, `reporting.routes.ts` is list + run only — there is no way to create, edit or delete a report definition, or manage its parameters. So the subsystem is read-only against whatever the platform happens to ship with, and an institution cannot add the one report its regulator asks for.

## Sub-tasks

Ordered. Dynamic parameter discovery comes first because it is the correctness fix — every later item builds on knowing what a report actually asks for.

## Scope

In scope: parameter discovery, cascading parameters, the renderers, output formats and download, and report definition management.

Out of scope: the content or correctness of the platform's own report SQL. The dashboard.

## Getting started

- `src/app/features/reporting/run-report.component.ts` (382 lines), `reports-list.component.ts`, `reporting.routes.ts`
- The platform's run-reports endpoint takes ten positional parameters covering the full filter set; only four are currently passed. **Read the signature carefully** — `src/app/api/api/runReports.service.ts:137` has seven consecutive optional strings, so an argument in the wrong position type-checks cleanly and sends the wrong value.
- Confirm behaviour against a live instance — `npm run e2e:stack`.

## Verification

Run a report that takes a loan officer parameter, with two different officers selected, and confirm the row sets differ. That is the check that proves parameter discovery works; a report that merely renders proves nothing.

Start with src/app/features/reporting/run-report.component.ts, reports-list.component.ts, reporting.routes.ts, and src/app/api/api/runReports.service.ts:137. Read the runReports signature carefully, then run npm run e2e:stack and inspect the existing report flow. Done means discovered parameters are passed in the correct positions and two loan officers produce different row sets, with the broader renderer and report-management scope addressed.

Written by the indexing model from the issue text.