feat(analyzer): add Korean bank account number recognizer (KR_BANK_ACCOUNT)

[juno-junho]

Change Description

Add KrBankAccountRecognizer (entity KR_BANK_ACCOUNT) under country_specific/korea/, registered in the predefined recognizer exports, default_recognizers.yaml (disabled by default, country_code: kr) and the supported entities docs.

Korean bank account numbers had no coverage. The patterns are ported from a production Korean PII-masking deployment, with conservative scores (no checksum exists for Korean accounts) and negative lookaheads for phone (010/070), RRN and date look-alikes. Plain 13-digit runs are deliberately left to KR_RRN's domain.

Tests: positive cases assert the best-scoring match per layout (the patterns overlap by design), and a look-alike table asserts zero matches for Korean phone numbers, RRN shapes, dates and short digit runs. The full analyzer suite (3047 tests) and ruff check pass.

Issue reference

Fixes #2214

Checklist

• I have reviewed the contribution guidelines
• I agree to follow this project's Code of Conduct
• I confirm that I have the right to submit this contribution and that it does not knowingly contain proprietary or confidential code.
• My code includes unit tests
• All unit tests and lint checks pass locally
• My PR contains documentation updates / additions if required

Update: aligned with the recognizer instructions from #2211

• Configuration-path test: the shipped entry is enabled, loaded through RecognizerRegistryProvider and exercised through AnalyzerEngine with a no-op Korean engine, asserting detection with the same score as direct construction. A negative case pins the instructions' warning: leaving the top-level supported_languages at the shipped ["en"] loads nothing, with no error. Enabling this entry therefore needs ko in the top-level languages (and in the NLP and analyzer engine languages).
• Context coverage: the Korean context words are shown to raise the score through the enhancer's explicit context argument (0.6 to 0.95), the same route test_context_support uses, since text-derived context needs a Korean NLP model the test environment does not ship. Context text on either side of the match is also covered at the pattern level.
• The YAML entry lists ko only (ISO 639-1), in its own commit. The neighbouring Kr* entries still carry kr, which fix(analyzer): remove a non-language code and a duplicate entry from default_recognizers.yaml #2236 traces back to a deliberate backward-compatibility alias from fix(analyzer): update Korean language code from 'kr' to 'ko' #1742 for recognizers whose class default used to be kr; this recognizer has only ever defaulted to ko, so there is no configuration that could depend on kr here. fix(analyzer): remove a non-language code and a duplicate entry from default_recognizers.yaml #2236 handles the existing entries.

[juno-junho]

Brought this in line with the recognizer instructions from #2211: a configuration-path test through RecognizerRegistryProvider and AnalyzerEngine that asserts detection, a negative case for the top-level supported_languages trap, the Korean context words shown to boost the score, and the YAML entry listing ko only. Details in the updated description.