Fix TODO keyword switching for Unicode keywords

[hiroakit]

Bugfix Overview

TODO keyword switching failed when TODO keywords contained non-ASCII characters (e.g., CJK/Hangul), because the heading matcher relied on an ASCII word-boundary check.
This PR updates TODO detection to use an explicit delimiter check and adds regression tests to cover Unicode keywords.

Problem

• Observed behavior:
  • With Unicode TODO keywords configured, org.incrementContext / org.decrementContext does not recognize the TODO context in headings, so switching does nothing (or becomes inconsistent).
• Expected behavior:
  • Headings should be recognized as TODO context and cycle through configured TODO keywords regardless of whether the keywords are ASCII or Unicode.

Reproduction Steps

1. Set org.todoKeywords to Unicode keywords (example: ["待办", "完成"]).
2. Create an Org heading like * Header.
3. Run Org: Increment Context (or press the bound key).
4. Expected: * 待办 Header -> * 完成 Header -> * Header (cycle). Observed (before): no switch / inconsistent switching.

Root Cause

• Cause:
  • The TODO heading regex used \b to detect keyword boundaries. In JS regex, \b is ASCII word-boundary based ([A-Za-z0-9_]) and does not work reliably for non-ASCII keywords.
• Why it was missed:
  • Existing tests only covered ASCII keywords (TODO, DONE) and did not include Unicode TODO keywords.

Fix

• Fix approach:
  • Replace the \b boundary check with a lookahead for expected delimiters after a TODO keyword (\s, [, or end-of-line).
  • Preserve “no keyword” behavior by treating any heading (* ...) as the empty TODO keyword context and cycling into the first configured keyword.
  • Add regression tests that set Unicode org.todoKeywords and validate increment/decrement cycling.
• Alternatives considered (if any):
  • Expanding the regex with hard-coded Unicode ranges. Rejected because it does not scale across scripts and is easy to get wrong.

Verification

• Manual verification
• Automated test added or updated
• Existing tests pass
• Screenshots or logs attached (if applicable)
• Test notes (commands, environment, datasets):
  • ✅ npm run compile
  • ✅ npm run lint
  • ✅ npm test

Impact / Risk

• Affected users:
  • Users configuring org.todoKeywords with Unicode keywords (Japanese/Chinese/Korean, etc.).
• Backward compatibility:
  • No breaking changes expected; ASCII keywords continue to work.
• Potential side effects:
  • Low risk; regex matching behavior is now based on explicit delimiters rather than \b.
• Mitigation or monitoring plan (if needed):
  • Covered by new regression tests for Unicode keyword cycling.

Related Issues / PRs

• Issue:
  • todo switching not works on unicode vscode-org-mode/vscode-org-mode#137
• Related PRs:
  • None

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.48%. Comparing base (0c458de) to head (d049cbe).
⚠️ Report is 1 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop      #43      +/-   ##
===========================================
+ Coverage    69.40%   78.48%   +9.07%     
===========================================
  Files           12       12              
  Lines         1010     1041      +31     
  Branches        48       58      +10     
===========================================
+ Hits           701      817     +116     
+ Misses         309      224      -85     

Files with missing lines	Coverage Δ
src/cursor-context.ts	76.10% <100.00%> (+7.50%)	⬆️
src/modify-context.ts	83.33% <100.00%> (+1.51%)	⬆️

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.