[ENHANCEMENT] prometheus: add instant mode to queries

[SoWieMarkus]

Description

This enhancement adds an instant query mode to the Prometheus time series query plugin, allowing individual queries to be executed as instant queries rather than range queries, independent of the panel-level query mode.

Previously, instant queries were only triggered by the panel context's mode field. With this change, a query-level instant flag can be set directly on the PrometheusTimeSeriesQuerySpec, giving users per-query control - similar to how Grafana handles this.

A prior attempt at instant query support (#738) was reverted because it broke the sparkline feature. A follow-up approach (#746) proposed coupling the query mode to the sparkline (instant for the stat value, range for the sparkline), but that approach has a drawback: instant and range queries can e.g. return a different number of time series if a series disappears within the configured time frame, leading to mismatches. This PR sidesteps that problem by attaching the instant flag to the individual query rather than the panel, decoupling it from sparkline behavior entirely. This way, the instant flag gives users explicit, unambiguous control over the query behavior.

Screenshots

Adds an instant toggle to the query:

instant also disables the sparkline:

Checklist

• Pull request has a descriptive title and context useful to a reviewer.
• Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the
  following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, DOC,IGNORE.
• All commits have DCO signoffs.

UI Changes

• Changes that impact the UI include screenshots and/or screencasts of the relevant changes.
• Code follows the UI guidelines.

[s3onghyun]

I think your approach is the better one, and it addresses exactly the objection @tgitelman raised on #746.

My PR was constrained by queryOptions returning a single panel-level { mode }: it could only ever pick one mode for the whole panel, so it couldn't give the value an instant query while the sparkline keeps a range query. That's the real fix here, and #746 couldn't express it. Worse, as you and @tgitelman both point out, a single shared range query can be wrong for the value anyway (Loki's split_queries_by_interval, series appearing/disappearing within the window) — so "value correct when sparkline off" was the most #746 could honestly claim, and even that's a narrow slice.

A per-query instant flag on PrometheusTimeSeriesQuerySpec is the right layer: it's explicit, it matches how Grafana does it, and it lets a stat panel run an instant query for the value and a range query for the sparkline as two independent queries. That decouples them properly instead of trying to infer one mode from the spec.

So I'd rather back #752 than push mine. I'll close #746 in favour of it. Two small things from my side that might be worth carrying over:

• The stat panel still needs to choose to issue an instant query for its value once the flag exists — happy to do that follow-up on the StatChart side once [ENHANCEMENT] prometheus: add instant mode to queries #752 lands, reusing the sparkline/calculation reasoning (only last is instant-safe; last-number, aggregations, and the sparkline need range).
• The regression tests I wrote for the sparkline case ([BUGFIX] Statchart: request instant queries for stat panels #738's failure) could move over so that path stays covered.

Nice work — this is the cleaner design.

[celian-garcia]

Cool feature ! Visually I'd vote for a segmented button like Grafana. The advantage is to really know what is the other option.

https://mui.com/material-ui/react-button-group/

[Nexucis]

Thank you for your time working on this topic @SoWieMarkus and @s3onghyun ! It is really cool to see the community working together to reach a consensus and bring a good solution to a broader problem.

regarding the go-sdk and the schema it looks good to me.
Over to the frontend maintainers to finish the review even if the changes look reasonable to me :)