Detail page renders Field.address values as raw JSON — the display registry has a location formatter but no address one #5075

Summary

On a record detail page, a Field.address value renders as a stringified JSON object instead of a formatted address. The create/edit dialog renders the same field correctly as Street / City / State / ZIP / Country inputs, so this is specific to the detail page's read renderer.

Decisive evidence — same record, same field group

Both fields sit in the same contact_info group on the same account record. The detail-page read renderer therefore has a location formatter and lacks an address one, so address falls through to stringifying the object.

This matches the shipped console bundle: the input registry carries both address: and location:; the display registry the detail page uses does not carry address.

The detail page's inline edit mode shows the JSON too.

Reproduce

1. Declare an address field on any object and give a record a value for it.
2. Open that record's detail page.
3. The value renders as raw JSON. Open the create/edit dialog for the same record — it renders correctly.

Scope

Type-level, not object-specific. Confirmed by writing a value to a second object's address field through the API and seeing the same rendering (reverted afterwards).

Why we have no app-side workaround

• Changing the field to text destroys the structured value and breaks the flat billing_country projection our territory sharing rules match on — and loses the sub-field inputs that currently work.
• A mirrored "display" field puts two addresses on the page that can drift apart.
• Authoring detail-page sections changes the value's source, not the renderer that formats it.

So we have recorded it as a known gap rather than papering over it.

Environment

@objectstack/* protocol ^17.0.0-rc.1, console served from @objectstack/console, driver-sql on SQLite, browser locale zh-CN.

Filed from a downstream app (hotcrm-heimao), tracked there as issue #54.