fix(codex): show project-local skills in composer - #7717

💭 The only in-scope file is ChatComposer.tsx, which adds a query for project skills and merges them in—not really a styling change. I want to check consistency issues like loading state handling and whether isPending is combined properly, along with verifying things like gitCwd and environmentId usage. Since the UI consistency check is mainly about shared components and Tailwind/CSS, and this diff has no styling changes, there may not be much to flag here. I want to check specific sections of ChatComposer, around lines 880-910, 1220-1240, and 3210-3230. I'm wondering whether there's a UI-consistency gap between mobile and web — mobile shows a loading state in the menu while skills load, but I need to check whether web's menu rendering condition handles the empty-items-plus-loading case the same way. I also want to verify that gitCwd is actually declared before it's used around line 893, since if its declaration comes later in the file that would trigger a temporal dead zone error. I need to find where isComposerMenuLoading is used, but the file search got cut off. Let me check the lines around where the menu renders and search for isLoading references instead. Grep is treating the file as binary, which suggests there's a stray null byte around offset 78151 — that could be a genuine issue. I should check whether this null byte was introduced by this PR or already existed before it, by comparing against the merge base. That NUL character is likely just a pre-existing unicode misread, not an actual issue. Now I want to check where isComposerMenuLoading gets passed and how the menu visibility logic is determined. I'm wondering whether isPending stays true when the query is disabled with a null input, since that could make the skill menu show a permanent loading state for non-codex providers or when there's no gitCwd, instead of falling through to results or an empty state. I need to check how useEnvironmentQuery behaves when passed null. I'm wondering whether background refetches with result.waiting could trigger a loading spinner even when cached items already exist, so I need to check how ComposerCommandMenu handles its isLoading state, and I notice the mobile version uses a similar pending check based on whether the trigger is a skill or path search. No regression there since loading only shows when empty, so the web behavior stays consistent. The diff is purely logic-based with no styling or shared primitive concerns, so nothing to flag on UI consistency—though I note the web gate checks the provider string directly while mobile checks a status driver field, which isn't a UI issue but worth noting. Given there are no actual findings, I'll conclude with "All clear" and set the state to success in the response.