fix(pulse/finances): non-USD amounts parse as zero, plus two adjacent data-loss bugs

[prafed]

Three defects in the Pulse Finances data layer, plus the frontend change needed to see the fix. Each bug produces a plausible-looking but wrong dashboard rather than a visible failure, which is why they're easy to miss.

Found while populating the Finances tab with real GBP data on a fresh install.

1. Non-USD amounts parse as zero

parseCurrencyCell strips $ and commas but not £ or €:

const cleaned = cell.replace(/\*\*/g, "").replace(/[~$,]/g, "").trim()

"£1,234" survives as "£1234", fails cleaned.match(/^[\d.]+/), and returns 0. Every row on a non-USD dashboard silently becomes zero — the tab renders normally and shows a total of 0.

Also now accepts the Unicode minus (U+2212), which typographic pipelines emit, so negative rows parse rather than being dropped by the amount > 0 filter in parseCurrencyTable.

USD behaviour is unchanged; regression cases below.

2. Obligation scope is hardcoded in two places

obligations.yaml can declare scope: business, but the value is overwritten with "personal" both in the YAML normalizer and again in the resolver. Fixing only the first has no visible effect, which makes this awkward to debug. Every business-paid obligation renders as personal.

3. Sample vendors silently delete real expenses

knownLabels is built from all vendors and obligations, then substring-matched against EXPENSES.md rows to avoid double-counting:

if (lower.includes(known) || known.includes(lower)) return false

Every row of the shipped install/USER/FINANCES/vendors.yaml is a zero-value unconfigured sample ("Sample Employer Inc.", "Sample Landlord", …). A user who fills in EXPENSES.md but leaves the sample file alone — it looks inert — has those sample names suppress their genuine expense rows.

On my install this removed roughly 40% of real expenses from the outbound total with no warning: the tab showed £32k against a true £55k.

A zero-value entry has nothing to double-count, so suppression is pure data loss. Only entries that actually contribute spend can now suppress a row.

4. Frontend: currency symbol from state.json

fmtHero/fmtExact hardcode $. They now read state.currency (already present in the API payload) and fall back to $ when absent, so existing installs are unaffected. Without this the parser fix is invisible: a GBP install shows $0 everywhere, then $98K.

Verification

Parser, including USD regression:

Input	Result
£1,234	1234
**£31,570.56**	31570.56
−£6,408.47	-6408.47
€2,500	2500
$1,234	1234
~$500	500
$12K	12000
£1.2M	1200000
-$50	-50
"" / n/a	0

End to end on a real GBP install: income and expense totals correct, obligations splitting business from personal correctly, and the Expenses tab total moving from the wrong £32k to the correct £55k once sample vendors stopped matching.

Happy to split this into separate PRs if you'd prefer them reviewed independently.