notion-effect-client: schema converge/provision cannot emit property descriptions, formulas, or views

Problem

The @overeng/notion-effect-client declarative provisioning / converge path — propDef builders feeding NotionDatabases.create and NotionDataSources.update — can only emit a subset of what @overeng/notion-effect-schema actually models. As a result, databases whose design depends on the un-emittable surfaces cannot be fully provisioned as code, and the missing pieces must be set by hand in the Notion UI, creating drift.

What the converge path emits today

• Property columns: title, rich_text, number, select, multi_select, date, url, checkbox, relation, rollup.
• select / multi_select options.
• Behavior is additive (add columns, add options) and fail-closed on type mismatch.

Modeled in @overeng/notion-effect-schema, but NOT emittable by converge

• Property description — PropertySchemaBase.description in src/property-schema.ts. This is the wholly-uncovered gap: per-property descriptions (e.g. an inline "how to file / what goes here" contract on each column) cannot be set declaratively at all.
• Formula expressions — FormulaPropertySchema.formula.expression in src/property-schema.ts. A database relying on a formula column (e.g. a completeness/validation check) can't have that column provisioned as code.
• Views — View / ViewType in src/objects.ts (with configuration currently an opaque Schema.Unknown). Views can't be created or converged declaratively.

Impact

A database whose design relies on a Notion formula column, per-property descriptions, or specific views cannot be fully provisioned from code. The author provisions what propDef supports, then manually fills in descriptions / formulas / views in the UI — exactly the manual exception the IaC converge path is meant to remove. There's no drift check on these surfaces either.

Acceptance criteria

• The converge path can declaratively set property description for properties it provisions, additively and idempotently.
• The converge path can set formula.expression for a formula property, additively and idempotently.
• The converge path can converge at least basic views (create + idempotent update of a simple view), additively.
• All three remain consistent with the existing posture: plan against freshly introspected live schema, additive by default, fail-closed for unsupported/destructive operations.
• Fake-gateway tests cover the update payloads; descriptions/formulas have a live-evidence or documented-demo proof where they mutate remote state.

Affected surfaces

• Builder: propDef
• Write path: NotionDataSources.update / NotionDatabases.create (@overeng/notion-effect-client)
• Schema models: PropertySchemaBase.description, FormulaPropertySchema.formula.expression, View/ViewType (@overeng/notion-effect-schema)

Related

Related: #698, #718, #720, #803. Note these track formulas (#718) and views (#720) for the @overeng/notion-datasource-sync sync package, and native status convergence (#803) — a different package / surface from the notion-effect-client propDef converge path described here, and none cover property descriptions. The epic owner may choose to fold this in.

Start by reading src/property-schema.ts and src/objects.ts, then trace propDef through NotionDatabases.create and NotionDataSources.update. Run the existing fake-gateway tests and verify payload coverage for descriptions, formula expressions, and basic views. Done means additive, idempotent convergence with fail-closed behavior plus live evidence or documented-demo proof for remote mutations.