Codegen: type token in ObjectTypeDefinition crashes schema deserialization

[lbialy]

Problem

maybeAsObjectTypeDefinition in ObjectTypeDefinitionProtoLike throws when the type field is anything other than None or "object". The latest TLS provider schema includes entries where type is a type token (e.g. "pulumi:providers:tls/terraformConfig") rather than a primitive type kind, causing initializationError in integration tests.

Example failing proto:

ObjectTypeDefinitionProto(
  Some(pulumi:providers:tls/terraformConfig),
  Map(__self__ -> PropertyDefinition(NamedType(#/provider,None),...)),
  List(__self__),
  None,
  false
)

Impact

This crashes all integration tests because CoreTests eagerly fetches the latest schema versions during class initialization.

Call sites affected

1. ObjectTypeDefinition.reader (line 669) — used by ResourceDefinition.stateInputs and FunctionDefinition.inputs, both non-optional fields that default to ObjectTypeDefinition()
2. ObjectTypeDefinitionOrTypeReference.reader (line 711) — branches on properties.nonEmpty and tries maybeAsObjectTypeDefinition first, but never falls back to maybeAsTypeReference when it fails

Current fix

Return None instead of throwing for unrecognized type values, with a warning. This means entries with type tokens in positions expecting ObjectTypeDefinition will be silently skipped (defaulting to empty).

Follow-up

We should investigate what semantics type tokens carry in these positions and whether we need to handle them properly (e.g. resolving the type reference, treating it as an alias, or generating different code).

Location

codegen/src/PulumiPackage.scala — ObjectTypeDefinitionProtoLike.maybeAsObjectTypeDefinition