Match display refs whose project prefix carries digits

[seungjuchoi]

Problem

In the TUI, pressing enter on a search result lands on the empty "no search results" view for every task that lives in a project whose prefix contains a digit.

Repro (hit this on my own data with v0.1.28):

1. Create a project whose key starts with digits, e.g. 00-main. prefix_base derives the prefix from the first character of each key word, so the project gets prefix 0M and its tasks display as 0M-XYMT.
2. Open the TUI, press /, and type something that matches such a task. The preview lists it fine.
3. Press enter. The list switches to the search view with no results, even though the row was right there a keystroke earlier.

Same thing from the CLI:

$ aven search fin
0M-XYMT  FinceptTerminal ...      # found

$ aven search 0M-XYMT
                                  # nothing

Alphabetic prefixes (AVN-RHGF) are unaffected, which is why this went unnoticed.

Root cause

Accepting a search result re-runs the search against the result's display ref (App::accept_search_result → accept_search_input(result.display_ref)), so the ref lane has to be able to parse PREFIX-SUFFIX back.

parse_ref_query only treated a leading group as a project prefix when it was entirely alphabetic:

if groups.len() >= 2 && groups[0].chars().all(|c| c.is_ascii_alphabetic()) {

But prefix_base takes the first character of each dash-separated key word, so digits are perfectly ordinary in a prefix (00-main → 0M, 01-loop → 0L, 03-lge → 0L2). For those refs the branch was skipped and the query fell through to the suffix-only branch, where 0M-XYMT collapses into 0MXYMT — which never prefix-matches the task id XYMTB8W8T3NRZDXY. No ref evidence, no results, empty view.

refs.rs::split_ref (used by show, edit, …) has always split on the first - without an alphabetic requirement, so aven show 0M-XYMT works and only search disagreed.

Fix

Treat any leading group of at most four characters as a prefix candidate. unique_project_prefix mints at most a three-character base plus a collision counter, so four is the real ceiling, and the length bound keeps ordinary hyphenated prose (release-cleanup) out of the ref lane the way the alphabetic check used to.

The prefix stays a hard filter against the project prefix in score_ref_lane, so /WRONG-7KQ9 still returns nothing.

Test

• task_search_parser_identifies_ref_shapes_for_numeric_project_prefixes covers 0M-XYMT, /0L2-7OKI, and that release-cleanup still parses as suffix-only.
• task_search_resolves_display_refs_for_numeric_project_prefixes seeds a 0M-prefixed project and walks the actual TUI round trip: preview a task, then re-search its display_ref and assert the task comes back with matched_field = Ref.

cargo test, cargo clippy --all-targets, and cargo fmt --check pass. The 8 failures I see in cli_sync / cli_workspaces / cli_daemon_sync / cli_inference_errors are pre-existing on main — the exec_sql helper shells out to my system sqlite3, which has no fts5 module.

I also re-ran every display ref in my own workspace (186 of them) through aven search and they all resolve now. The only refs that still don't are recurrence series refs (RCR-…), which are a separate matter — happy to send that as its own PR.

[raine]

Thanks!