Audit extra_json fields for promotion to explicit DB columns

[dmwyatt]

Problem

Several model structs have explicit fields that silently land in extra_json in the database because they don't have corresponding DB columns. While extra_json is a useful catch-all for API evolution, frequently-used fields stored there are a bug vector — they require extra.get("field_name") extraction which is error-prone and hard to grep.

This was the root cause of the audio_source bug (#240): the source field was in the model but extracted from extra HashMap during DB insert.

Scope

Review these entities for fields that should be promoted from extra_json to explicit DB columns:

documents

Model fields not in DB: user_id, workspace_id, visibility, creation_source, privacy_mode_enabled, status, sharing_link_visibility, notes (JSON)

people

Model fields not in DB: user_id, avatar, user_type, subscription_name, links, favorite_panel_templates, created_at

events (calendar events)

Model fields not in DB: recurring_event_id, ical_uid, status, html_link, creator, organizer

Decision criteria

A field should be promoted to an explicit column if:

• It is used in queries (WHERE, ORDER BY, JOIN)
• It is displayed in command output
• It is extracted via extra.get() anywhere in the codebase
• It would benefit from indexing

Fields that are only stored and never read individually can stay in extra_json.

Related

• #241 — parent audit issue
• #240 — audio_source bug caused by this pattern