fix(db): disable useDefineForClassFields so entity updates stay updates

[Danswar]

Root-cause fix for #205 (the data cleanup follow-up stays tracked there).

What

One line in tsconfig.json — "useDefineForClassFields": false — plus a regression spec that pins the semantics.

Why

Commit e18f05a (#84) bumped target from es2017 to es2022, which silently flips TypeScript's useDefineForClassFields default to true. Since then, every entity produced by repo.create() / new Entity() carries all declared columns — including id — as own properties initialized to undefined. The update helpers merge with Object.assign(dbEntity, freshEntity), which copies id: undefined onto the loaded row, so save() issues an INSERT instead of an UPDATE:

• transaction_onchain has UNIQUE ("transaction") → the 02:00 nightly sync has aborted with UQ_8a233973 duplicate-key errors every night since 2025-11-11 (verified in Loki: 55 dup-key errors/night on PRD, 3/night on DEV — exactly the table row counts — and zero syncOnchainTransactions: runtime= success lines in 30 days).
• transaction_lightning has no unique constraint → the same pattern silently inserts duplicate rows: the 03:00 sync's entries= count compounded 369 → 1250/night over the last week, and websocket state transitions create new rows instead of updating.

Setting the flag back to Set semantics restores exactly the behavior the codebase ran with before November and fixes all four Object.assign-merge sites at once (lightning-transaction.service.ts ×2, lightning-wallet.service.ts, user-boltcard.service.ts).

Verification

• Regression spec fails on the unfixed tsconfig (row id gets wiped to undefined) and passes with the fix; ts-jest compiles specs with the repo tsconfig, so it also guards against a future re-flip.
• npm run build, npm run test (30/30), npm run lint all green locally.
• After deploy: the nightly Error during processSyncOnchainTransactions should disappear and a syncOnchainTransactions: runtime= line should appear; transaction_lightning should stop growing at the sync rate.

Not in this PR

• Dedupe of the duplicate transaction_lightning rows accumulated since November (needs FK remap of user_transaction.lightningTransactionId) — follow-up per Entity updates broken since es2022 target bump: nightly onchain sync aborts on dup-key, transaction_lightning silently accumulates duplicate rows #205.
• UNIQUE (type, transaction) on transaction_lightning — only possible after the cleanup.

[TaprootFreak]

Reviewed: explicitly disabling define-style class fields restores the pre-ES2022 entity semantics across all affected Object.assign update paths, and the regression test pins both the own-property and preserved-id behavior. CI is green. The required duplicate-row cleanup remains tracked in #205, now assigned to Danswar: #205.