Made Astro Client Side Test Fairer

[AlexanderKaran]

• Updated Astro Client Side Methodology description
• Remove ClientSide Router as it's not needed for client-side and just ops in view transitions. In most frameworks, you have to opt in for view transitions, so it's not fair to add it for Astro.

@dreyfus92 Please add a better description if I did a shit job above lol

Another fix for #194

Might be able to close the Astro check now

[dreyfus92]

quick note on why we decided to remove <Clientrouter />:

<Clientrouter /> and csr are two different things. what actually makes this test client-only is the directive client:only="react" on the table island not clientrouter. that's what keeps the table out of the initial html, and lighthouse waiting on table tbody after hydration/render is the behavior we care about.

clientrouter is basically just "hey astro, enable view transitions api". it gives mpa apps that soft spa-like navigation feel, but it's optional. it doesn't enable csr, and you don't need it for a client only island to work.

so including it here felt a bit off because:

we're benchmarking client-rendered ui, not optional navigation/transitions most other frameworks in the suite don't include transition/router behavior by default for csr (usually opt-in) keeping it would bake in an astro-specific optional feature that isn't really part of a typical csr setup

the react + client:only approach, react isn't required for client-only in astro (you could do a client <script> or another integration), but it's a reasonable default and closer to how a lot of astro apps ship interactive islands. a plain script-generated table would be more baseline html/js and less "astro-y", so imo keeping react here makes sense.