[UnigramDev/Unigram/search-tabs-negative-index](https://github.com/UnigramDev/Unigram/tree/search-tabs-negative-index) • [7b9967e](https://github.com/UnigramDev/Unigram/commit/7b9967eb5bc57ffca3d137157dbeb392adabd6c2) • _1 files, +13/-8_
Keep SelectedTab in range instead of guarding its readers

Per review: nothing deselects a tab, so the question was where -1 comes from.

TopNavView.SelectedIndex is bound TwoWay, and a selector reports -1 whenever it
holds no selection — which it does while its ItemsSource is being attached.
BindableBase.Set stores the value and raises the notification before returning,
so the existing guard, which ran after Set and only checked the upper bound,
had already let -1 into the field. Tabs[value] on the next line was reading at
-1 too; the reported crash simply landed later, in Query, on the next
keystroke.

Validating before the value is committed keeps the field in range for every
reader — Query, ItemsView, IsTopChatsVisible and the setter itself — so the
guard added to Query in the first commit is no longer needed and is reverted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

[#unigram](?q=%23unigram)