[Ticket]: Distinguish budget backend not configured from an outage

## Type

Bug

## Summary

We need to distinguish "budget backend not configured" from a real outage because
`server/env.ts:173` silently falls `budgetUrl` back to `backendUrl` while the proxy always appends
`/budget/rpc/…`, so a missing config 404s exactly the way a real outage would, and an operator
cannot tell them apart from the `/admin` screen.

Expected result:
> A missing `budgetUrl` configuration is reported distinctly (in logs and, ideally, in the UI) from
> a genuine upstream failure.

## Intent

Operators debugging "Could not load the refill queue." need to know immediately whether this is a
deployment misconfiguration (fix the config) or a real incident (page someone / wait it out). Today
both produce an identical failure, which wastes incident-response time chasing the wrong cause.

## Source of truth (links)

- https://github.com/ADORSYS-GIS/converse-frontends/blob/main/apps/console/src/server/env.ts#L173
- https://github.com/ADORSYS-GIS/converse-frontends/blob/main/apps/console/src/server/proxy-target.ts#L45-L48
- https://github.com/ADORSYS-GIS/converse-frontends/issues/281

## Current Behavior

`apps/console/src/server/env.ts:173`:

```ts
budgetUrl: trimTrailingSlash(asStringWithFallback(raw.budgetUrl, backendUrl)),
```

If `budgetUrl` is unset, it silently becomes `backendUrl`. The proxy
(`apps/console/src/server/proxy-target.ts:45-48`) always appends `/budget/rpc/…` to whatever
`budgetUrl` resolves to. If the budget service is not actually reachable at `backendUrl` + that
suffix, every `/admin` call 404s — identical in shape to a real outage of a correctly-configured
budget backend. The UI shows "Could not load the refill queue." in both cases.

## Expected Behavior

When `budgetUrl` is not explicitly configured (and the fallback to `backendUrl` is not a valid
substitute in this deployment), the misconfiguration is detectable and reported distinctly from a
runtime outage — at minimum in server logs at startup/request time, and ideally surfaced to the
operator-facing UI as "budget backend not configured" rather than a generic load failure.

## Acceptance Criteria

- [ ] Given `budgetUrl` is unset in config, when the server starts or the first `/admin` request is
made, then the misconfiguration is logged distinctly from a request failure.
- [ ] Given a genuine upstream 5xx/timeout from a correctly-configured budget backend, then the
failure surface (log and/or UI) is visibly different from the misconfiguration case.
- [ ] Error cases are handled safely — this change does not turn a working deployment (where the
`backendUrl` fallback happens to be correct) into a false-positive misconfiguration warning.
- [ ] Existing behavior is not broken for deployments with `budgetUrl` correctly set.
- [ ] Relevant tests are added or updated.
- [ ] Verification evidence is provided.

## Out of Scope

- Changing the fallback behavior itself (whether `budgetUrl` should default to `backendUrl` at all)
— this ticket is about diagnosability, not about removing the fallback.
- Building UI beyond what is minimally needed to surface the distinction.

## Technical Context

Relevant files: `apps/console/src/server/env.ts` (config parsing, `budgetUrl` fallback),
`apps/console/src/server/proxy-target.ts:45-48` (`budgetRpcTargetUrl`). Consider whether `env.ts`
should track and expose "was `budgetUrl` explicitly set" as a boolean alongside the resolved value,
so downstream error handling can reference it without re-deriving it.

## Risks

Risk: over-eager misconfiguration detection could fire false positives for deployments that
deliberately share the backend and budget URL. Mitigation: only flag it as a possible
misconfiguration signal alongside the actual request failure, not as a standalone hard error at
startup.

## Test Plan

Unit test for the config-parsing layer confirming an explicit-vs-fallback distinction is tracked.
Manual verification: run with `budgetUrl` unset against a backend that does not serve
`/budget/rpc/*` and confirm the failure is now distinguishable from a mocked outage.

## Verification evidence

To be filled in by the implementing engineer at PR time: log output showing the distinction, and/or
a UI screenshot of the misconfiguration state.

## Human accountable owner

@stephane-segning

## AI Usage Declaration

Ticket decomposition

## Human verification completed

- [ ] I understood the intent
- [ ] I checked the source of truth
- [ ] I reviewed all AI-generated text/code
- [ ] I verified the implementation manually
- [ ] I verified the tests
- [ ] I checked for hallucinated assumptions
- [ ] I documented remaining risks
- [ ] I am the accountable owner and accept responsibility for this ticket.