Fix crash: replace usesAutomaticRowHeights with deferred self-sizing

[beezly]

Problem

NSHostingView inside NSTableView with usesAutomaticRowHeights enters an infinite layout loop when SwiftUI view content changes during layout. AppKit detects this and crashes with NSGenericException:

The window has been marked as needing another Update Constraints in Window pass, but it has already had more Update Constraints in Window passes than there are views in the window.

The crash reproduces when scrolling into rooms containing video/image messages with reactions or read receipts. It is timing-dependent — more likely when launched from Finder than under a debugger.

Root Cause

During layout, NSHostingView.layout() flushes SwiftUI transactions. If the SwiftUI view tree has changed (e.g. async content loaded), this calls invalidateIntrinsicContentSize, which triggers constraint updates, which re-enters layout — exceeding AppKit's constraint update pass limit (one pass per view in the window).

This was latent since the NSTableView rewrite (#47) but became reliably triggerable as view complexity grew (reactions, read receipts, video playback).

Fix

Replace the entire auto-sizing mechanism with SelfSizingHostingView:

• sizingOptions = [] — prevents the hosting view from participating in Auto Layout constraint solving
• invalidateIntrinsicContentSize() overridden to schedule a coalesced async height update instead of calling super (which would re-enter the constraint system)
• measureHeight() temporarily re-enables sizing, pins a width constraint matching the column width, reads fittingSize, then resets — all outside the layout pass
• heightOfRow returns cached heights (default 60px); noteHeightOfRows called with animation duration 0

Also removes the old measurementHostingView (separate NSHostingController per height query) and handleTableResize observer.

Depends on

• Fix: reduce timeline flickering with incremental updates #80 (fix: reduce timeline flickering with incremental updates)