[PB Extension] Add command to open lexicon selector

[imnasnainaec]

Register lexicon.openSelector(projectId) for the interlinearizer (sillsdev/interlinearizer-extension#44). It is a thin wrapper on ProjectManager.openSelector() that resolves the project manager from a project id.

It refuses a project that already has a lexicon. Selection is sticky: to relink, clear the project's lexicon.lexiconCode setting first.

It reports whether the selector opened, not whether a lexicon was chosen. The chosen lexicon lands in lexicon.lexiconCode, which a caller can watch.

No UX change a user of this extension on its own can see.

Fixes #2683

Drafted by Claude Opus 5

---

Devin review: https://app.devin.ai/review/sillsdev/languageforge-lexbox/pull/2684

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: 333ffddd-01fd-4a62-8c96-ceb09dd54e49

📥 Commits

Reviewing files that changed from the base of the PR and between 1cf6cf1 and ecd5d67.

📒 Files selected for processing (2)

• platform.bible-extension/src/main.ts
• platform.bible-extension/src/types/lexicon.d.ts

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The extension adds lexicon.openSelector, resolves the project manager, opens the selector, and returns its result. Activation awaits command registration. JSDoc documents the command result and lexicon setting behavior.

Changes

Lexicon selector command

Layer / File(s)	Summary
Command registration and contract platform.bible-extension/src/main.ts, platform.bible-extension/src/types/lexicon.d.ts	The extension registers lexicon.openSelector. The handler returns failure when the project manager is unavailable and otherwise returns the selector result. Activation awaits registration. JSDoc documents the result and lexicon.lexiconCode behavior.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Feature

Merge Risk: ⚪ Minimal · up to ecd5d

The selector command preserves the intended result and registration behavior; no merge-blocking risk remains.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 2 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The pull request addresses issue #2683 and matches the linked objective.
Out of Scope Changes check	✅ Passed	The changes are limited to registering the requested command and documenting its handler.
Description check	✅ Passed	The description clearly explains the new lexicon.openSelector(projectId) command, its behavior, and its relationship to the linked issue.
Title check	✅ Passed	The title clearly and concisely identifies the main change: adding a command to open the lexicon selector.

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{A rabbit taps the selector bright
A project opens into light
The lexicon waits, calm and clear
Its chosen code is written here
The command returns what opened right
And activation waits in sight}

_{Comment @coderabbitai help to get the list of available commands.}

[myieye]

This looks ok to me, but I'm puzzled as to why it's being added.
It's essentially identical to the command that's marked for future deletion lexicon.changeLexicon.

Should it actually block somehow if a lexicon is already selected?
Should it be coupled with a second command for explicitly, intentionally clearing the current lexicon? Or should a flag be added to lexicon.openSelector to make overriding a current lexicon explicitly allowed?

[imnasnainaec]

This looks ok to me, but I'm puzzled as to why it's being added. It's essentially identical to the command that's marked for future deletion lexicon.changeLexicon.

Should it actually block somehow if a lexicon is already selected? Should it be coupled with a second command for explicitly, intentionally clearing the current lexicon? Or should a flag be added to lexicon.openSelector to make overriding a current lexicon explicitly allowed?

Fair questions! A substantial difference from lexicon.changeLexicon now exists... just added a block when a lexicon is already selected (7cfd9fe).

The desired route (at least for now) to clear the lexicon is to delete it via the project settings. We can add override later if a use-case demands it.

[myieye]

Looks good 👍🏻