Refactor computeVisibleOptionGroups

[mjbvz]

Refactors computeVisibleOptionGroups to be more accurate and hopefully readable. This doesn't get the code into a perfect state but it's better than it was

I have broke this refactoring into a number of commits with comments explaining the change I am making and some of the thought behind each step. One important note is that these are not 100% safe refactorings. This was more of an exercise to show the process how I'd try to understand this single function and clean it up

Some general points:

• Renaming to give accurate names can be a great way to understand the code and make ugly parts of it obvious

• It's better to have ugly parts of the code be obvious than hide them away. A name like getOptions may be nice and clean looking but a more accurate name like getOptionsFromServerAndUpdateCacheAndMaybePromptTheUserIfItsAprilFoolsDay is better if that's what the method actually does

• It's ok to make code more ugly as part of refactoring so long as the ugliness is honest

• Breaking up code can help you understand how it works, the dependencies between the different parts, and see when one method/function is doing way too much

• Strive for code blocks that have a single clear responsibility. That responsibility may be very abstract and high level or it may be very low level. Either way, code that does more than one thing is a great candidate for being broken up

• I also find it's useful to try separating out the stateless parts of the code from the stateful parts. This makes the stateless parts easier to reason about and test, and hopefully lets you reduce and isolate state in the longer term

• Assume no one will read the docs because largely no one will. Instead try designing apis that are self documenting and suggest the correct use (and more importantly, are difficult to misunderstand/misuse)

• You can use renaming and extraction as a way to understand code. This is useful to do even if you have no intention of ever checking in the refactoring.

• Agents can be a great tool for making refactorings, especially ones that traditional refactoring tools would never support. However current agents are not so good at automatically refactoring on their own. They aren't even great when you prompt them to refactor to improve code quality. You have to provide very detailed instructions about what you want

• If you can't understand the code, coding agents will struggle with it too. If the code isn't understood, it will keep getting worse

[Copilot]

Pull request overview

This PR refactors how ChatInputPart computes visible chat session option groups and updates related context keys, aiming to centralize picker visibility logic and reuse it across session-type changes, rendering, and picker refresh.

Changes:

• Replaces computeVisibleOptionGroups() with smaller helpers that return visible option groups and update context keys.
• Updates picker creation/refresh flows to use sessionResource explicitly via a new getCurrentSessionResource() helper.
• Adjusts effective session type resolution to return undefined instead of '' and updates call sites accordingly.