feat(prometheus): expose an instant PromQL query as a provider method

[dngr2]

Fixes #6475

What was actually missing

The provider can already run instant queries — _query() hits /api/v1/query with the configured basic auth. What was missing is any way to reach it: PROVIDER_METHODS was empty, so the UI and agents report methods: [], which is what the issue shows.

So this is an exposure change, not a new query implementation. No change to the endpoint, the auth handling or the error behaviour.

The change

• query_instant(query: str) -> dict, a public wrapper over the existing _query()
• declared in PROVIDER_METHODS as a read-only view, scoped to connectivity (the provider's existing scope)

Why the tests check the declaration and not just the call

ProvidersFactory.__get_methods reflects methods with:

inspect.signature(provider_class.__dict__.get(method.func_name))

A func_name that doesn't resolve on the class itself — a typo, or a method that is inherited rather than defined here — makes that inspect.signature(None), which raises when the provider is loaded, not when the method is called. The tests assert that invariant, and that every scope a method declares exists in PROVIDER_SCOPES.

Reflection output with this change:

name: Query Prometheus | func_name: query_instant
type: view | scopes: ['connectivity']
params: [('query', 'str', True)]

Tests

New file: tests/providers/prometheus_provider/test_prometheus_query_method.py

Against unmodified main: 8 failed, 2 passed — the 2 are loop-based guards that pass vacuously while PROVIDER_METHODS is empty, so they are regression protection rather than evidence. With the change: 10 passed.

• the method is declared, resolves on the class, and its scope exists
• the endpoint and params sent for an instant query
• the response envelope returned unchanged
• empty query rejected; non-200 raises
• basic auth used when credentials are set, omitted when they are not

tests/providers in full: 63 passed. I have not run the suites needing Docker and a database locally — leaving those to CI.

Question before I extend this

I have deliberately left out /api/v1/query_range. It needs start/stop/step and a decision about capping result size, and the issue only asks to run PromQL. Happy to add it in this PR if you'd like it — I'd rather ask than guess at the parameter shape.

Worth noting separately: _query() sends its request with no timeout, so a slow or hanging Prometheus will block the caller. I left that alone to keep this focused, but I'm glad to open a separate PR for it.