Issue triage from the command palette compares against pingdotgg/t3code, not Lazurio/t3code

What

Upstream v0.1.4 adds issue triage to the command palette (pingdotgg#22753). The server clones and compares https://github.com/pingdotgg/t3code (T3CODE_REPOSITORY_URL in apps/server/src/triage/TriageService.ts), and the palette offers the action when the environment reports capabilities.triage.

Why it matters

On Lazurio T3 Code the source the triage reads is upstream, not Lazurio/t3code. An issue a person hits in an overlay feature would be triaged against code that does not have the overlay, and the result can point them to upstream.

Question

For the Lazurio distribution, should triage be hidden (the server not reporting capabilities.triage), pointed at Lazurio/t3code, or left as it is? The v0.1.4 rebuild (#143) keeps upstream's behaviour unchanged; any change would be a new overlay row or a small addition to an existing one, and an offer to upstream to make the repository configurable.

Found by the T3 Release bot while rebuilding onto v0.1.4.

Decided and fixed in row 15 of the v0.1.6 rebuild, #152 (head 0ddf6f4628), decision I in #148: a Lazurio Environment triages nothing. The descriptor no longer advertises capabilities.triage, so the palette offers no triage, and guardTriage, where server.ts builds upstream's TriageService, refuses prepare. The t3 triage command stays upstream's, as on v0.1.3: a person runs it in a terminal and it asks before creating anything. serverBrowser.test, a server test and the release contract test pin the capability, the refusal and its one construction.

This stays open until main carries the fix.