refactor(config): externalize rpcAccessProducts to config/rpc_products.yaml

The Chain 138 RPC access product catalog (core-rpc / alltra-rpc /
thirdweb-rpc, each with VMID + HTTP/WS URL + tier + billing model + use
cases + management features) used to be a hardcoded 50-line Go literal
in api/rest/auth.go. The review flagged this as the biggest source of
'magic constants in source' in the backend: changing a partner URL, a
VMID, or a billing model required a Go recompile, and the internal
192.168.11.x CIDR endpoints were baked into the binary.

This PR moves the catalog to backend/config/rpc_products.yaml and adds
a lazy loader so every call site reads from the YAML on first use.

New files:
  backend/config/rpc_products.yaml           source of truth
  backend/api/rest/rpc_products_config.go    loader + fallback defaults
  backend/api/rest/rpc_products_config_test.go  unit tests

Loader path-resolution order (first hit wins):
  1. $RPC_PRODUCTS_PATH (absolute or cwd-relative)
  2. $EXPLORER_BACKEND_DIR/config/rpc_products.yaml
  3. <cwd>/backend/config/rpc_products.yaml
  4. <cwd>/config/rpc_products.yaml
  5. compiled-in defaultRPCAccessProducts fallback (logs a WARNING)

Validation on load:
  - every product must have a non-empty slug,
  - every product must have a non-empty http_url,
  - slugs must be unique across the catalog.
  A malformed YAML causes a WARNING + fallback to defaults, never a
  silent empty product list.

Call-site changes in auth.go:
  - 'var rpcAccessProducts []accessProduct' (literal) -> func
    rpcAccessProducts() []accessProduct (forwards to the lazy loader).
  - Both existing consumers (/api/v1/access/products handler at line
    ~369 and findAccessProduct() at line ~627) now call the function.
    Zero other behavioural changes; the JSON shape of the response is
    byte-identical.

Tests added:
  - TestLoadRPCAccessProductsFromRepoDefault: confirms the shipped
    YAML loads, produces >=3 products, and contains the 3 expected
    slugs with non-empty http_url.
  - TestLoadRPCAccessProductsRejectsDuplicateSlug.
  - TestLoadRPCAccessProductsRejectsMissingHTTPURL.

Verification:
  go build ./...       clean
  go vet ./...         clean
  go test ./api/rest/  PASS (new + existing)
  go mod tidy          pulled yaml.v3 from indirect to direct

Advances completion criterion 7 (no magic constants): 'Chain 138
access products / VMIDs / provider URLs live in a YAML that operators
can change without a rebuild; internal CIDRs are no longer required
to be present in source.'

backend/config/rpc_products.yaml

@@ -0,0 +1,97 @@
+# Chain 138 RPC access product catalog.
+#
+# This file is the single source of truth for the products exposed by the
+# /api/v1/access/products endpoint and consumed by API-key issuance,
+# subscription binding, and access-audit flows. Moving the catalog here
+# (it used to be a hardcoded Go literal in api/rest/auth.go) means:
+#
+#   - ops can add / rename / retune a product without a Go rebuild,
+#   - VM IDs and private-CIDR RPC URLs stop being committed to source as
+#     magic numbers, and
+#   - the same YAML can be rendered for different environments (dev /
+#     staging / prod) via RPC_PRODUCTS_PATH.
+#
+# Path resolution at startup:
+#   1. $RPC_PRODUCTS_PATH if set (absolute or relative to the working dir),
+#   2. $EXPLORER_BACKEND_DIR/config/rpc_products.yaml if that env var is set,
+#   3. the first of <cwd>/backend/config/rpc_products.yaml or
+#      <cwd>/config/rpc_products.yaml that exists,
+#   4. the compiled-in fallback slice (legacy behaviour; logs a warning).
+#
+# Schema:
+#   slug:                string (unique URL-safe identifier; required)
+#   name:                string (human label; required)
+#   provider:            string (internal routing key; required)
+#   vmid:                int    (internal VM identifier; required)
+#   http_url:            string (HTTPS RPC endpoint; required)
+#   ws_url:              string (optional WebSocket endpoint)
+#   default_tier:        string (free|pro|enterprise; required)
+#   requires_approval:   bool   (gate behind manual approval)
+#   billing_model:       string (free|subscription|contract; required)
+#   description:         string (human-readable description; required)
+#   use_cases:           []string
+#   management_features: []string
+
+products:
+  - slug: core-rpc
+    name: Core RPC
+    provider: besu-core
+    vmid: 2101
+    http_url: https://rpc-http-prv.d-bis.org
+    ws_url: wss://rpc-ws-prv.d-bis.org
+    default_tier: enterprise
+    requires_approval: true
+    billing_model: contract
+    description: >-
+      Private Chain 138 Core RPC for operator-grade administration and
+      sensitive workloads.
+    use_cases:
+      - core deployments
+      - operator automation
+      - private infrastructure integration
+    management_features:
+      - dedicated API key
+      - higher rate ceiling
+      - operator-oriented access controls
+
+  - slug: alltra-rpc
+    name: Alltra RPC
+    provider: alltra
+    vmid: 2102
+    http_url: http://192.168.11.212:8545
+    ws_url: ws://192.168.11.212:8546
+    default_tier: pro
+    requires_approval: false
+    billing_model: subscription
+    description: >-
+      Dedicated Alltra-managed RPC lane for partner traffic, subscription
+      access, and API-key-gated usage.
+    use_cases:
+      - tenant RPC access
+      - managed partner workloads
+      - metered commercial usage
+    management_features:
+      - subscription-ready key issuance
+      - rate governance
+      - partner-specific traffic lane
+
+  - slug: thirdweb-rpc
+    name: Thirdweb RPC
+    provider: thirdweb
+    vmid: 2103
+    http_url: http://192.168.11.217:8545
+    ws_url: ws://192.168.11.217:8546
+    default_tier: pro
+    requires_approval: false
+    billing_model: subscription
+    description: >-
+      Thirdweb-oriented Chain 138 RPC lane suitable for managed SaaS access
+      and API-token paywalling.
+    use_cases:
+      - thirdweb integrations
+      - commercial API access
+      - managed dApp traffic
+    management_features:
+      - API token issuance
+      - usage tiering
+      - future paywall/subscription hooks