fix(priority): fix numeric priority highlighting, cycling, and sorting

[liamrlawrence]

Summary

Numeric priorities (org_priority configured as numbers, e.g. a 1–15 range)
were broken in two ways:

• Config:get_priorities built the priorities table with mixed key types when
  numeric priorities were configured: highest/default/lowest under raw
  number keys ([1], [5], [15]), intermediate values from PriorityState as
  strings (["2"], ["3"]). Since [1] and ["1"] are distinct keys, the
  treesitter org-is-valid-priority? predicate — which looks priorities up by
  string text from the [#N] cookie — missed the boundary entries, breaking
  highlighting and cycling at those values.
• PriorityState:prompt_user and :get_sort_value used string.byte, which
  only reads the first character, so multi-digit input like "10" was misvalidated
  and sorted by leading digit (e.g. "10" ranked above "9", "1" is equal to "13").

To better understand the broken behavior, you can apply the commit
test(priority): add failing tests before applying the patches.
Most (but not all) of the new tests will fail, highlighting the above issues.

Changes

• Normalize highest/default/lowest priority table keys with tostring.
• Use PriorityState._as_number (uses tonumber for numeric priorities and
  string.byte for letter priorities) in both prompt_user and get_sort_value.
• Add tests to better cover numeric priority edge cases

Checklist

I confirm that I have:

• Followed the
  Conventional Commits
  specification (e.g., feat: add new feature, fix: correct bug,
  docs: update documentation).
• My PR title also follows the conventional commits specification.
• Updated relevant documentation, if necessary.
• Thoroughly tested my changes.
• Added tests (if applicable) and verified existing tests pass with
  make test.
• Checked for breaking changes and documented them, if any.