feat(swift): add Basic Catalog component schemas and registry

[pinieb]

Summary

Adds the standard Basic Catalog component schemas and registry to the Swift Core SDK, defining all 18 standard A2UI components and 14 built-in client functions across supported specification versions (v0.9, and v0.9.1).

Note: This PR depends on the validation checks and property resolution changes in the base PR.

Key changes

• Component schemas (BasicCatalogComponents.swift):

  • Implemented JSON schemas for all 18 standard Basic Catalog components:
    • Layout and containers: Row, Column, List, Card, Tabs, Modal, Divider
    • Display: Text, Image, Icon, Video, AudioPlayer
    • Inputs and controls: Button, TextField, CheckBox, ChoicePicker, Slider, DateTimeInput
  • Added BasicCatalogComponents.allComponents to expose the full list of ComponentAPI definitions.

• Function registry (BasicFunctions.swift):

  • Added BasicFunctions.allFunctions aggregating all 14 standard client-side functions: and, email, formatCurrency, formatDate, formatNumber, formatString, length, not, numeric, openUrl, or, pluralize, regex, and required.

• Catalog factory and constants (BasicCatalog.swift):

  • Defined canonical catalog URIs for v0.9, and v0.9.1.
  • Added standard themeSchema for Basic Catalog surfaces.
  • Added createCatalog helper and preconfigured instances (v09Catalog, v091Catalog, allCatalogs).

Verification

Ran the Swift test suite:

cd swift/core && swift test

[gemini-code-assist]

Code Review

This pull request introduces validation checks, nested property resolution, typed property accessors, and a pre-configured BasicCatalog containing standard components and functions. Feedback on these changes suggests optimizing performance by converting computed properties (allFunctions and allComponents) to static let constants, coercing .standard properties to .dynamicValue early in resolveProperty when a binding is detected, and removing a redundant object resolution block in SurfaceViewModel.swift.

[pinieb]

/gemini review - This has been rebased several times, and I think some of your initial comments were on changes in earlier branches. Could you please do a complete review again?

[gemini-code-assist]

Code Review

This pull request introduces the BasicCatalog module, which provides pre-configured catalog instances, 18 standard component API definitions, and basic client-side functions across supported A2UI specification versions. The feedback suggests optimizing allComponents in BasicCatalogComponents by changing it from a computed property to a static let constant to avoid unnecessary allocations.

[pinieb]

@jacobsimionato Just wanted to call your attention to this one, since part of #2401 was ditching the CatalogAPI vs Implementation split. This isn't in there to split the Catalog across module boundaries anymore, but instead to support a slightly nicer API surface for clients.

Since MessageProcessor ends up erasing the Catalog types anyways, having this protocol lets clients hand in a heterogenous array of Catalog instances without first having to manually do the type erasure.

In multi-framework scenarios, it takes the call site from MessageProcessor(catalogs: [MyUIKitCatalog.impl.eraseToAnyCatalog(), FancySwiftUICatalog.impl.eraseToAnyCatalog(), SuperPizzazzCustomUIFramework.impl.eraseToAnyCatalog()]) to MessageProcessor(catalogs: [MyUIKitCatalog.impl, FancySwiftUICatalog.impl, SuperPizzazzCustomUIFramework.impl])

[jacobsimionato]

No worries! This solution sounds great to me - the majority of the code still follows the share structure, and this makes it ergonomic with Swift's type system.

[jacobsimionato]

Thanks for iterating!!

[jacobsimionato]

I'm not a swift readability expert, but would toAnyCatalog() be a little neater?

[jacobsimionato]

I think we can remove this now, right? Because the object itself conforms to ComponentApi. You could return self here, but better to just have the callers use self directly I imagine!