[Security] Bump vendored FlatBuffers past v25.12.19 for verifier/memory-safety fixes (coordinated with zlmdb)

[oberstet]

Summary

autobahn vendors FlatBuffers as a Git submodule, currently
deps/flatbuffers at 7e163021e59cca4f8e1e35a7c828b5c6b7915953 (v25.12.19), and also ships a
built flatc. Since v25.12.19, upstream has landed a cluster of verifier-hardening and
out-of-bounds fixes that are directly relevant because autobahn may parse
attacker-controlled FlatBuffers (verifier / reflection / FlexBuffers paths) and the bundled
flatc may be run against untrusted schemas.

Bump the vendored submodule to the latest upstream revision (pinned commit SHA) available at 26.9.1
release time, regenerate any generated code, and rebuild the bundled flatc.

This MUST be coordinated with zlmdb (see the companion zlmdb issue): both vendor FlatBuffers and
autobahn.check_zlmdb_flatbuffers_version_in_sync() + test_zlmdb_flatbuffers_in_sync assert the two
versions are equal. zlmdb is currently at the same commit (7e163021, v25.12.19). Bumping one
without the other turns that test red. Land both to the same target commit.

Why (relevant upstream fixes since v25.12.19)

A Python package scanner will not flag vendored C++, so this is an engineering-review item. Upstream
has addressed, among others:

• FlexBuffers verifier / ToString() heap-buffer-overflow — a malformed buffer passes
  verification and then triggers an OOB read in ToString() (upstream issue #9041, reported CVSS 7.5 High).
• Reflection verifier hardening against malformed schemas.
• OOB checks in memcpy_downward.
• FlexBuffers OOB protection in Map::Keys().
• OOB protection in GetBufferStartFromRootPointer().
• Text-generation OOB fixes.
• Additional verifier hardening for malformed schemas and field IDs.

That is a significant cluster for a serialization library exposed to untrusted input.

What to do

• Pick the target upstream commit (latest stable/tagged, or master at a pinned SHA) at release time.
• Update deps/flatbuffers submodule to that commit identical to zlmdb's.
• Regenerate vendored/generated Python code as needed; rebuild the bundled flatc.
• Bump the vendored FlatBuffers __version__ accordingly.
• Confirm autobahn.check_zlmdb_flatbuffers_version_in_sync() passes against the coordinated zlmdb bump.
• Run the FlatBuffers serialization tests + test_zlmdb_flatbuffers_in_sync; CI green on CPython + PyPy.
• CHANGELOG 26.9.1 "Security" entry.

Acceptance criteria

• deps/flatbuffers at the chosen post-25.12.19 commit, equal to zlmdb's vendored commit.
• Version-in-sync check + tests pass; generated code + bundled flatc regenerated from the new revision.
• The verifier/OOB fixes above are present in the vendored revision.

Notes / links

• Companion issue: crossbario/zlmdb — same bump, kept in lock-step.
• Rationale for the coupling is in the check_zlmdb_flatbuffers_version_in_sync() docstring
  (autobahn = data-in-transit, zlmdb = data-at-rest; both must share a compatible FlatBuffers runtime
  for Crossbar.io interop).
• Part of the 26.9.1 security track (dependency-floor review + [CI/Security] Automated dependency-audit workflow (pip-audit + osv-scanner) publishing a reproducible security evidence base as a nightly-release artifact #1949 evidence base).