Bug: jira.priority_map.* config is ignored, bd push/pull fails on Jira projects with non-default priority names

[alexanderv-sifi]

Summary

jira.priority_map.* config keys are accepted by bd config set but are
never actually read during Jira sync. Any custom priority-name mapping is
silently ignored — all conversion falls back to the hardcoded
Highest/High/Medium/Low/Lowest strings. This breaks bd push and
bd pull on any Jira project that uses non-standard priority names.

Version

Reproduced on v1.0.0 (Homebrew install, and current main at 77cad4a4).

Steps to reproduce

1. Point beads at a Jira project that uses a non-default priority scheme
   (for example, one using Normal instead of Medium).
2. Configure the mapping:

   bd config set jira.priority_map.0 "Critical"
   bd config set jira.priority_map.1 "High"
   bd config set jira.priority_map.2 "Normal"
   bd config set jira.priority_map.3 "Low"
   bd config set jira.priority_map.4 "Low"

3. Create a beads issue at priority 2 and push it:

   bd create --title "test" --priority 2 --type bug
   bd push

Expected

The issue is created in Jira with the Normal priority, per the configured
mapping.

Actual

bd push fails with:

jira API returned 400: {"errors":{"priority":"Specify the Priority (name) in the string format"}}

Jira rejects the request because beads sends the hardcoded string Medium,
which doesn't exist on the target project. P0 and P1 happen to sync
because the hardcoded Highest/High collide with defaults on many Jira
instances — anything from P2 downward fails.

Root cause

Three functions convert priorities using hardcoded maps and never consult
the config:

• internal/jira/fieldmapper.go — PriorityToTracker (beads → Jira)
• internal/jira/fieldmapper.go — PriorityToBeads (Jira → beads)
• internal/jira/tracker.go — jiraPriorityToNumeric (Jira API → numeric)

The jira.priority_map.* keys are never loaded into the jiraFieldMapper
struct, so there's nothing for these functions to consult. Compare with
jira.status_map.* and jira.type_map.*, which follow the documented
pattern and work correctly.

Related

• Fix jira.priority_map.* config not read on push/pull #3130 — proposed fix (loads jira.priority_map.* into jiraFieldMapper
  following the existing statusMap/typeMap pattern)
• docs: tracker sync documentation should disclose field mapping limitations and data loss #1573 — tracker sync field mapping limitations (adjacent, documentation-focused)