Full Dashboard (deprecated): Trace Flag Changes grid throws InvalidCastException now that the view returns rows #1660

Found by the issue audit as a follow-up to #1635. The fix there was correct and the reporter's scenario is genuinely resolved — this is the next failure it exposed, not a regression of it.

What happens

config.trace_flags_history.status is bit NOT NULL (install/03_create_config_tables.sql:430), and report.trace_flag_changes projects it through untouched:

previous_status = rc.previous_status,
new_status      = rc.status,

(install/47_create_reporting_views.sql:1126-1127 — no CONVERT to text)

The deprecated Dashboard reads both as strings:

• deprecated/Dashboard/Services/DatabaseService.SystemEvents.cs:469-470 — reader.GetString(2) / reader.GetString(3)
• deprecated/Dashboard/Models/TraceFlagChangeItem.cs:12-13 — both declared string

SqlDataReader.GetString performs no conversion and throws InvalidCastException on a bit column.

Why it only surfaces now

Before #1635, the view itself failed with Msg 245 the moment a toggle row flowed through it, so the reader never got to run. Now that the view returns rows, execution reaches the cast and fails there instead. Affected surfaces: the Dashboard's Trace Flag Changes grid and the get_trace_flag_changes MCP tool, which share that method (deprecated/Dashboard/Mcp/McpConfigHistoryTools.cs:129).

Direct SQL consumers of the view — including the Grafana companion @argpna was building — are unaffected and correctly fixed.

Suggested fix

Change the reader, not the view: read the bit and format it C#-side.

The view's column shape is a public contract for anyone querying report.trace_flag_changes directly, and someone is already doing exactly that. Converting the columns to 'ON'/'OFF' text in SQL would fix the Dashboard while silently breaking those external queries — the wrong trade.

Scope: deprecated, bug-fix-only, and not shipped in release artifacts, so low priority. Lite and Darling are unaffected; they diff trace flags in C# via the shared PerformanceMonitor.Common.ConfigChangeDiff and never touch this view.

Related: a CI blind spot worth its own look

Nothing would have caught this. .github/sql/ci_validate_installation.sql:128 validates report.* views by OBJECT_ID existence only and never selects from them, so an entire bug class — view compiles and exists, but throws or mistypes on execution — is invisible to CI. #1635 was itself exactly that class, reported by a user rather than caught by a build.