fix: read parenthesised accounting negatives on paste

[jlc488]

The bug

(1,234) — the parenthesised negative that Excel's accounting format and most ERP exports produce — parsed to 1234, silently flipping the sign on pasted money. For a library whose pitch is money-safe canonical values in legacy Korean business forms (JSP/eGovFrame, ERP exports), that's a correctness bug rather than a formatting nicety.

before:  parse('(1,234)', { negative: true })  →  '1234'
after:   parse('(1,234)', { negative: true })  →  '-1234'

The fix

parse normalizes the input once (full-width parens （） included) and reads the parenthesised form as negative when negative is on. Deliberately conservative:

• the parens must actually enclose digits → (주)한국 1234 is untouched
• currency signs may sit outside them → ₩(1,234), (1,234)원
• a minus inside the parens doesn't negate twice → (-1,234) → -1234
• positive-only fields ignore the form entirely → (1,234) → 1234
• parens stay insignificant for caret math, so cursor behaviour is unchanged

Trailing-sign notation (1234-, mainframe exports) is deliberately not included — it's ambiguous against live typing, unlike the paren form.

Verification

• 4 new test cases (90 passing), typecheck + build green.
• Also verified in a real browser, since this repo has a history of DOM-path bugs that whole-value jsdom tests missed: pasting (1,234) into a bound negative field displays -1,234 and getValue() returns -1234; ₩(1,234.56) → -1,234.56; a positive-only field still shows 1,234.

Docs: Notes bullet in both READMEs, CHANGELOG 0.4.2, version bumped.