fix: stop report cells accepting typing that goes nowhere

[laurentiu021]

Closes #2105 — and corrects that issue's numbers, which I had inflated.

What was wrong

Ten text cells across AppUpdatesView and WindowsUpdateView entered edit mode on a double-click. Typing there changed the in-memory row and nothing else, so the app appeared to accept an edit it silently discarded.

One of them carries a consequence: App Updates' Id is the value WingetService.UpgradeAsync builds winget upgrade --id "…" from, so retyping it turns a row that would have upgraded into a row that reports an error.

Per-column, not grid-level — and the issue got this backwards

#2105 read the situation as "20 views set IsReadOnly on the DataGrid, these forgot". That was wrong, and setting it globally would have broken the feature:

Every grid lacking IsReadOnly has a selection mechanism that needs the grid editable. Six use DataGridCheckBoxColumn (App Updates, Windows Update, App Blocker, DNS & Hosts, Shortcut Cleaner, Uninstaller) and two use a DataGridTemplateColumn with a CheckBox. DataGrid.IsReadOnly="True" renders a DataGridCheckBoxColumn untickable — it would have disabled "Upgrade selected" outright. None of the 20 read-only grids has a checkbox column, which is why they can afford the grid-level form.

So the fix is IsReadOnly="True" on the ten text columns, leaving every checkbox, button and template column exactly as it was.

The count in #2105 was inflated, and by what

The issue's table said App Updates 6, Windows Update 10 of 11, plus five more views — 27 typeable cells in total. Re-measured: 10 cells across 2 views.

The pattern I measured with, <DataGridTextColumn[^>]*?/?>, also matches <DataGridTextColumn.CellStyle> — a property element, not a column. There are 43 of those across the views, so the population read as 168 instead of 125, and every per-view number carried a share of them. Shortcut Cleaner, Uninstaller, Context Menu and Startup were listed as having typeable cells and have none; their text columns already carry the attribute per column.

Recording it here rather than quietly shipping the smaller fix, because the same pattern is now in the guard and its floor documents the trap.

Environment Variables is the one deliberate exception

Its Value column stays editable, and the tab settles it: Apply / Discard / Restore backup sit beside the grid, and the binding is UpdateSourceTrigger=PropertyChanged, which exists to carry each keystroke to the view-model for Apply to write. Inline editing is the feature. Marked with a comment in the XAML and named in the guard's exception list with that reason, so a uniformity sweep cannot "fix" it.

The guard

EveryReportTextColumn_IsReadOnly — a DataGridTextColumn must be read-only via its own attribute or via a grid whose every <DataGrid> tag sets it, with the exception list keyed to view + column header. Vacuity floor at 118 against 125 measured, and the remark records the property-element trap so the next person measuring does not repeat it.

Verification

Mutation proof, three files restored byte-for-byte:

Mutation	Result
App Updates' Id loses IsReadOnly	RED, naming AppUpdatesView.xaml: Id
Windows Update's Status loses it	RED, naming WindowsUpdateView.xaml: Status
the Environment Variables exception is removed	RED, naming EnvironmentVariablesView.xaml: Value

The third confirms the allowlist is load-bearing rather than decoration. Baseline and post-restore green.

265 cases green across ArchitectureTests, AppUpdatesViewModelTests, WindowsUpdate* and EnvironmentVariables*. Builds 0 errors / 0 warnings, dotnet format --verify-no-changes clean on both, version consistency csproj 1.76.14 = CHANGELOG 1.76.14 = SECURITY 1.76.x.

Not verified here: that the cells are actually inert on screen, which needs the app running. What is verified is that the attribute is on all ten columns and that no checkbox column was touched — the XAML parses, and the grid-level form (which would have broken selection) is explicitly rejected by the guard's failure message.