Dynamic attribute metadata stops replicating once a table's shared-structure slots are exhausted (peers answer 'unknown attribute' until reconnect)

The sender-side log confirms the mechanism: each healthy iteration logs `send table struct 0 ` (structure count grew → `TABLE_FIXED_STRUCTURE` re-sent, carrying the attribute list); from iteration 32 on, records are sent with no preceding structure message.

## Root cause

Attribute metadata has **no replication path of its own** — it piggybacks on the structure-length gate:

```ts
// replication/replicationConnection.ts (sender, per audit record)
if (typedStructs?.length != tableEntry.typed_length || structures?.length != tableEntry.structure_length) {
…
ws.send(encode([TABLE_FIXED_STRUCTURE, { typedStructs, structures, attributes: table.attributes, schemaDefined: … }, …]));
}
```

When the structure count stops changing (cap reached — also: any new attribute whose records reuse an existing shape), the gate never fires again. The receiving side (`ensureTableIfChanged`, ~6168) merges attributes correctly whenever it *does* get the message — the defect is purely that the sender stops sending.

Related, same root cause, previously observed by QA exploration (QA-380, 2026-06-26): an explicit `create_attribute` on one node never propagates at all — `addAttributes` → `table()` emits no replication event, and with no subsequent record write minting a new shape, the structure-length gate never fires either.

## Impact

- Long-lived dynamic tables with evolving record shapes (> 32 distinct shapes — easily reached in heterogeneous-ingest workloads) silently stop propagating new attributes cluster-wide; remote nodes serve 500s for queries naming those attributes while holding the data.
- Self-heals only on connection re-establishment, which can be arbitrarily far away on a stable cluster.
- Not data loss (records replicate and are readable via known attributes / `*`), but silent cross-node schema divergence with a wrong-error surface, and remote indexes for the affected attributes lag until reconnect.

## Suggested direction

Give attribute metadata a first-class trigger rather than widening the piggyback:

1. Sender-side: gate the `TABLE_FIXED_STRUCTURE` re-send on `table.schemaVersion` (bumped by `core/resources/databases.ts table()` on any attribute change) *in addition to* structure length. Cheap (integer compare per record), fixes both the cap case and the reused-shape case; the explicit-`create_attribute`-with-no-writes case additionally needs a proactive push (e.g. the sender's schema-change ITC listener marking the table dirty and flushing a `TABLE_FIXED_STRUCTURE` even without a following record).
2. Alternatively (stronger invariant): the receive-apply path could create missing attributes from the records it applies, making "a dynamic table's attribute set covers every record it stores" hold regardless of the metadata channel — but that adds per-record property inspection to the apply hot path, so option 1 is likely the right cost/benefit.

## Discovery context