feat(install-wizard): support unresolved mapped objects in amp.yaml

[dionlow]

Summary

Adds runtime support for amp.yaml read objects declared with only a mapToName (no concrete objectName). When the InstallWizard encounters one, it prompts the user for the provider-side object name, fetches its field metadata via getObjectMetadataForConnection, and hydrates the manifest with the resolved object so downstream configuration continues unchanged.

• New useObjectMetadataForConnectionQuery hook (wraps ObjectsFieldsApi.getObjectMetadataForConnection).
• New ResolvedMappedObjectsProvider holds mapToName → resolution and seeds from an existing Installation.config on re-entry.
• useManifest merges resolutions into the hydrated revision; every downstream consumer (tabs, fields, mappings, draft, review) stays oblivious to the pre-resolution state.
• New ResolveMappedObjectSubPage — text input + inline error + submit; on success swaps the wizard's selection entry from mapToName → resolved objectName.
• SelectObjectsStep and ObjectTabs render a "Needs setup" badge for unresolved objects.
• ConfigureObjectsStep gates on unresolved objects and adds an Edit affordance for ones that were previously resolved.
• WizardContext gains a REPLACE_SELECTED_OBJECT action that preserves currentObjectIndex.

Design doc: MAPPED_OBJECT_RESOLUTION_PLAN.md.

Backend dependencies (confirm before merging)

• HydratedIntegrationObject may arrive with empty/missing objectName and a populated mapToName.
• Installation.config.read.objects[<resolvedName>] must be accepted on create with a user-chosen objectName that isn't in the manifest, and must be echoed back on read so the wizard can rehydrate previously resolved objects.

Test plan

Fixture setup

• Point a test project at an amp.yaml that declares at least one read object with mapToName + mapToDisplayName but no objectName (e.g. mapToName: customContacts).
• Ensure the backend returns the unresolved object in getHydratedRevision (objectName empty, mapToName set).

Happy path

• SelectObjectsStep lists the unresolved object by its mapToDisplayName with a "Needs setup" badge. Selecting it works.
• On ConfigureObjectsStep for the unresolved tab, ResolveMappedObjectSubPage renders with the prompt "Which object represents <mapToDisplayName>?".
• Submit disabled while input empty; disabled while request is in-flight.
• Submitting a valid provider object name (e.g. contacts) transitions into the normal FieldsContent flow with the provider's fields populated.
• Completing configuration through to Review → Install succeeds.
• Inspect the createInstallation payload: config.content.read.objects[<resolvedName>].objectName === <resolvedName> (not the mapToName).

API error path

• Submit a non-existent object name; the sub-page shows an inline error and keeps the input enabled.
• Correcting the name and resubmitting recovers (no stale error state).

Edit affordance

• After resolution, navigate to the object's tab — the title shows an "Edit" link.
• Clicking Edit returns to ResolveMappedObjectSubPage; the badge/state reverts to unresolved.
• Submitting a different name re-hydrates fields with the new metadata (and previous draft entries are cleaned up).

Rehydration (re-entering an existing installation)

• With a previously installed integration that used a resolved mapped object, reopen the wizard.
• The resolved object's tab opens directly to FieldsContent (no ResolveMappedObjectSubPage).
• "Edit" is still available to change the selection.

Regressions

• Integrations that use only concrete objectName read objects still render unchanged through Select → Configure → Review → Install.
• The standalone Configure flow (non-wizard) is unaffected — it uses useManifest outside the ResolvedMappedObjectsProvider, which falls back to an empty resolutions map.
• yarn tsc --noEmit clean; yarn lint produces no new errors.

🤖 Generated with Claude Code