Decide: support apisix-standalone backend (and its cache layer)?

Summary

`adc` supports three backends: `apisix` (cluster mode), `api7ee`, and `apisix-standalone` (single-node, config-via-API). The standalone backend in adc ships with a per-instance cache layer that tracks the last-known full config so subsequent syncs can skip the full "PUT every resource" cycle when nothing changed.

a7 currently targets API7 EE only. This issue asks: do we want a7 to also drive standalone APISIX, and if so, do we need the cache?

Context

• adc cache implementation lives in `adc/libs/backend-apisix-standalone/src/` and tests in `adc/libs/backend-apisix-standalone/e2e/cache.e2e-spec.ts` (~440 lines).
• The cache exists because standalone APISIX accepts the entire config as one PUT; without a cache, every sync re-uploads everything even when there are no diffs.
• API7 EE has a real Admin API with per-resource endpoints, so a7 doesn't need this cache today.

Two questions

1. Should a7 support standalone APISIX at all?

Arguments for:

• broader user base — community APISIX users could share tooling with API7 EE users,
• matches `adc` feature parity exactly,
• standalone is the easiest way to demo a7 (no etcd cluster).

Arguments against:

• a7 is positioned as the "official API7 EE CLI"; widening scope blurs the product story,
• maintenance cost — every `config` subcommand grows a per-backend branch,
• the multi-backend abstraction in adc is non-trivial (per-backend resource transformations, separate validation paths).

2. If yes to (1), how is the cache stored?

Options:

• on-disk under `~/.config/a7/cache/{backend-id}.json` keyed by gateway-group/server URL,
• in-memory only (no skip on subsequent runs — defeats the point),
• never cache — always upload full config (simple, but loses the perf win).

Why deferred

Identified during the adc → a7 test parity audit (see `docs/adc-test-parity-plan.md`). Unlike the other deferred items, this one is scope-first, not work-first — we need a product call before any code is meaningful.

Definition of done

A documented decision (in `AGENTS.md` or `docs/`) on:

1. whether a7 will support apisix-standalone (yes / no / future),
2. if yes, the cache strategy and any user-visible CLI changes (`--backend` flag, etc).

If "no", close this and remove the corresponding `[N]` entries from the test-parity plan as out-of-scope rather than gaps.

Read docs/adc-test-parity-plan.md and the issue's referenced cache implementation at adc/libs/backend-apisix-standalone/src/, then review adc/libs/backend-apisix-standalone/e2e/cache.e2e-spec.ts. The work is complete when AGENTS.md or docs/ records whether standalone APISIX is supported and, if so, the cache strategy and user-visible CLI changes; otherwise remove the related parity entries.