Migrate tenant onboarding from in-object ApplicationSet mutation to a Git directory generator

The post-confirmation Lambda currently mutates the `openclaw-tenants`
ApplicationSet **in the cluster** (server-side apply on the list generator's
`elements`), which:

1. **Bypasses Git as the source of truth** — a GitOps anti-pattern in a
teaching sample; Argo CD will show the object as managed while its tenant
list only exists in etcd.
2. **Hits the ~1.5 MiB etcd object cap** in the low thousands of tenants —
the entire tenant list lives in a single object.

Proposed direction: switch the ApplicationSet to a **Git directory generator**
(one file per tenant); the Lambda commits a tenant file to the config repo
instead of patching the cluster object. Needs an ADR covering: repo/credential
model for the Lambda, commit contention, and rollback semantics.

Surfaced during the scaling-limits analysis (docs/scaling-limits.md). Part of #5.

Start with docs/scaling-limits.md, then locate the post-confirmation Lambda and the openclaw-tenants ApplicationSet it currently mutates. Define the Git directory generator and tenant-file flow, and add an ADR covering the Lambda's repository credentials, commit contention, and rollback semantics; done means tenant onboarding no longer relies on in-cluster list mutation.

Written by the indexing model from the issue text.