GeezerVison

Reviewed the new indexed JSON/Debezium encoder path (encode_indexed, JsonEncoder::new, the new validate rules), the rewritten buffer-size accounting in the non-indexed encode loop, the new tombstones_on_delete config (Rust and Java), the Debezium schema change, the CSV index rejection, and the profiler frontend refactor. No vulnerability was confirmed: the message-size accounting in both the indexed and non-indexed paths is exact or fail-closed (and now includes key bytes, closing a pre-existing over-limit case), the index/key_schema pairing is structurally guaranteed by the catalog, attacker-controlled records cannot multiply per-key output or panic the error formatter, and the SQL panel renders bundle content as escaped text with no raw-HTML sink. Remaining observations are author-only configuration and correctness nits that cross no trust boundary.

• Can the new indexed encoder path be made to overflow the transport's max-buffer-size limit or panic on attacker-controlled data?
  The `required` size check equals the bytes actually pushed for both array modes, per-key output is bounded to one `before` and one `after` by `indexed_operation_type`, and the error formatter is UTF-8-safe and length-bounded.
• Does the rewritten non-indexed buffer accounting drop records, underflow, or let a keyed message exceed the transport limit?
  The rewrite is purely additive with no subtraction left, `prev_len` truncation is always in range, deferred records keep their weight and sequence number, and including `key_buffer` makes the guard stricter than before.
• Can a connector config reach the index encoder in an unsafe or unsupported state, or bypass transport capability checks?
  `is_index` is derived from the same condition that forces `index_handles` resolution, which only yields handles with a key schema, and the residual mismatches fail the author's own endpoint at runtime rather than crossing any security boundary.
• Does the support-bundle viewer render bundle-supplied SQL or config through an unescaped HTML sink, or let one user's bundle break another user's session?
  No `{@​html}` sink exists on the bundle path, Monaco `setValue` is a plain text buffer, the new `sqlPanel` snippet has no production consumer, and bundle parsing is entirely client-side.
• Is the unguarded `program_code.split('\n')` in the bundle parser a reportable availability issue?
  Server-generated bundles always carry a string `program_code`, and the TypeError is caught by the load guard and shown as escaped text in the opener's own tab only.
• Should `array: true` combined with an index be treated as a security issue?
  It only affects the output shape of a sink the author configured themselves, is the documented meaning of the `array` option, and has no size-accounting or memory-safety consequence.