Three registered control views never bind Style/Class at all — they derive from ComponentBase #1333

Three views are registered in BlazorViewRegistry through the same StandardView<TControl, TView>
helper as every other control view — but they derive from plain ComponentBase instead of
BlazorView<,>:

They take [Parameter] ViewModel / Stream / Area by hand, so BlazorView.BindData — the method
that binds Id, Class and Style for every control view — never runs for them.

Why this is a different defect from #1297, not part of it

#1297 is about views that bind Style/Class and then drop them in markup: the fields hold the
right value and the razor never writes it out. That is a markup fix, one line per view, and it is what
#1323 / #1327 / #1332 did for all 25.

Here nothing is dropped in markup because nothing arrives. The fields do not exist. Fixing it means
answering a view-base question first, and the answer is not obviously the same for all three:

• Re-base on BlazorView<TControl, TView> — correct in principle (they are control views; the
  registry already treats them as such) but each hand-rolls the parameter and subscription handling
  that the base owns, so this is a rewrite of their lifecycle, not an attribute edit. SearchBoxView
  in particular drives a MonacoEditorView with its own @ref + value plumbing.
• Or bind the two parameters by hand — smaller, but it leaves three views permanently outside the
  contract the base class documents, which is how this class of bug keeps recurring.

Either way it needs its own change and its own tests; it was deliberately kept out of the #1297 sweep
so a 25-view markup fix did not turn into a lifecycle refactor.

What "done" looks like

Controls-level parity with every other registered view: a declared Style and Class reach the DOM,
an undeclared one changes nothing, pinned by a render test in ControlStyleRenderingTest (which now
covers 25 views the same way). Worth deciding at the same time whether StandardView<,> should
require a BlazorView<,>-derived component, so a fourth instance cannot be registered silently — that
generic constraint is the thing that would have made this impossible to introduce in the first place.

Found by the audit in #1288, tracked separately per the resolution in #1297.