docs: cut 6.1.0 versions for docs, admin_docs, developer_docs, components

Snapshots all four versioned Docusaurus sections at v6.1.0. Built on
top of the version-cutting tooling work in chore/docs-cut-6.1.0-versions
so the snapshot benefits from:

- Auto-gen refresh before snapshotting (database pages from engine
  spec metadata, API reference from openapi.json, component pages
  from Storybook stories) — captured at the SHA we cut from rather
  than whatever happened to be on disk.
- Data-import freeze: country list, feature flag table, database
  diagnostics, and component metadata are copied into snapshot-local
  `_versioned_data/` dirs so the historical version doesn't silently
  mutate when the source files change.
- Depth-aware import-path rewriter that handles deeply-nested
  component MDX files referencing `../../../src/` from the snapshot.

Versioning behavior: `lastVersion` stays at `current` for every
section, so the canonical URLs (`/docs/...`, `/admin-docs/...`,
`/developer-docs/...`, `/components/...`) continue to render content
from master. The `current` version is consistently labeled "Next"
with an `unreleased` banner, and `6.1.0` is a historical pin
accessible only via its explicit version segment.

Component playground: previously `disabled: true` in versions-config.json,
now enabled and versioned. The plugin block in docusaurus.config.ts
was already gated only by the `disabled` flag, so no other code
changes were needed to bring it back online.

The frozen `databases.json` in the snapshot is the canonical 80-database
artifact from the latest committed state in master (preserved by the
generator's input-hash cache), not a fallback regenerated from a
local Flask environment.

docs/admin_docs_versioned_docs/version-6.1.0/configuration/event-logging.mdx

@@ -0,0 +1,62 @@
+---
+title: Event Logging
+sidebar_position: 9
+version: 1
+---
+
+# Logging
+
+## Event Logging
+
+Superset by default logs special action events in its internal database (DBEventLogger). These logs can be accessed
+on the UI by navigating to **Security > Action Log**. You can freely customize these logs by
+implementing your own event log class.
+**When custom log class is enabled DBEventLogger is disabled and logs
+stop being populated in UI logs view.**
+To achieve both, custom log class should extend built-in DBEventLogger log class.
+
+Here's an example of a simple JSON-to-stdout class:
+
+```python
+    def log(self, user_id, action, *args, **kwargs):
+        records = kwargs.get('records', list())
+        dashboard_id = kwargs.get('dashboard_id')
+        slice_id = kwargs.get('slice_id')
+        duration_ms = kwargs.get('duration_ms')
+        referrer = kwargs.get('referrer')
+
+        for record in records:
+            log = dict(
+                action=action,
+                json=record,
+                dashboard_id=dashboard_id,
+                slice_id=slice_id,
+                duration_ms=duration_ms,
+                referrer=referrer,
+                user_id=user_id
+            )
+            print(json.dumps(log))
+```
+
+End by updating your config to pass in an instance of the logger you want to use:
+
+```
+EVENT_LOGGER = JSONStdOutEventLogger()
+```
+
+## StatsD Logging
+
+Superset can be configured to log events to [StatsD](https://github.com/statsd/statsd)
+if desired. Most endpoints hit are logged as
+well as key events like query start and end in SQL Lab.
+
+To setup StatsD logging, it’s a matter of configuring the logger in your `superset_config.py`.
+If not already present, you need to ensure that the `statsd`-package is installed in Superset's python environment.
+
+```python
+from superset.stats_logger import StatsdStatsLogger
+STATS_LOGGER = StatsdStatsLogger(host='localhost', port=8125, prefix='superset')
+```
+
+Note that it’s also possible to implement your own logger by deriving
+`superset.stats_logger.BaseStatsLogger`.