docs(lakefs): add the Alauda support for lakeFS installation guide

[SuJinpei]

Installation guide for the S2 ecosystem plugin Alauda support for lakeFS (lakeFS 1.84.1, upstream
chart 1.12.18), packaged by the oss-operator-factory and published to the Alauda Cloud marketplace
(cn app 967 / io app 837).

Follows the convention already used by the knative / nacos / debezium / konveyor guides:
hand-authored prose with factory:auto fenced slots for supported-versions and known-limitations, so
later releases regenerate those without touching the prose. No id: field, so CI assigns a real KB
id on merge.

What the guide leads with, and why

The storage decision, before installation — because that is where a lakeFS install actually goes
wrong. The shipped defaults are an embedded metadata store on the container filesystem, which is
single-replica and not durable, and it is easy to mistake "it installed" for "it is ready to use".
The guide gives all three shapes explicitly — out-of-the-box, evaluation-with-a-PVC, production with
PostgreSQL + S3 — and the one-volume-at-/home/lakefs rule that makes the middle one work.

Everything here was executed, not transcribed from upstream docs

Commands come from the validated e2e path: lakectl invoked from inside the image against the
Service, the exact convergence checks the release gate uses, and the uninstall ordering (delete the
LakeFS resource before the Operator, or the namespace hangs in Terminating) — which is the
failure this release actually hit during onboarding.

The second commit is a correction worth reading

The first version documented lakeFS's unattended installation.* setup with no qualification. While
running the production-shape e2e leg (PostgreSQL + S3) I found that it does not apply when the
metadata store is PostgreSQL: the server starts normally, connects to PostgreSQL — it creates its
partitioned kv tables and writes to them — initialises the S3 adapter, and then stays
{"state":"not_initialized"}, rejecting every API call with credentials not found.

Established rather than assumed:

• not a race — still uninitialised minutes after boot, on a freshly created database, reproduced
  twice;
• isolated with a control — two deployments identical except database.type: the embedded one
  comes up initialized and the configured key works, the PostgreSQL one does not.

A reader following the original text for a production deployment would have got something that
starts cleanly and then refuses to work. It is now scoped to evaluation, with the caveat, the
/app/lakefs setup escape hatch (which mints its own key pair and ignores any configured one), a
pointer from the production section, and a Known Limitation entry.

Once set up, the production shape is fully functional — verified end to end: repository on
s3://<bucket>/<repo>, upload → commit → branch → merge → read back, objects physically present in
the object store, and the S3-compatible gateway serving them.

Validation

Frontmatter parses; no id: on the new file; relative anchors resolve. yarn build does not run
locally (it dies in SSG on localStorage.getItem is not a function inside @alauda/doom, a
module-load failure independent of page content) — CI builds fine.