[Bug]: Entity validation rejects untyped ("any") properties the platform accepts, blocking base44 dev

[rmoskal]

Description

The CLI's entity validation (PropertyDefinitionSchema) requires type on every property. The Base44 platform accepts, and the Builder itself generates, properties with no type ({}), meaning "any value". An app containing such a schema cannot run any CLI command that loads entities, including base44 dev.

Same class of problem as #543: the CLI's validation is stricter than the platform.

Steps to Reproduce

1. Have an entity whose schema contains an untyped property, e.g. an audit log storing before/after values of any shape:

   "field_changes": {
     "type": "array",
     "items": {
       "type": "object",
       "properties": {
         "field": { "type": "string" },
         "previous_value": {},
         "new_value": {}
       }
     }
   }

2. Run base44 dev.

Expected Behavior

The CLI accepts any schema the platform accepts. A property without type is treated as "any".

Actual Behavior

base44 dev exits before starting:

Error: Invalid entity file in .../base44/entities/AuditLog.jsonc:
✖ Invalid input
  → at properties.field_changes.items.properties.previous_value.type
✖ Invalid input
  → at properties.field_changes.items.properties.new_value.type
  Hint: Fix the schema/data structure errors in .../base44/entities/AuditLog.jsonc

The schema was created in the Builder and works in production.

Environment

• OS: Fedora 44 (Linux 7.2.5)
• Node.js version: 24.12.0
• CLI version: 0.1.16 (0.1.14 behaves the same)

Additional Context

In PropertyDefinitionSchema, type is z.union([z.string(), z.array(z.string())]) with no .optional(). Making it optional would match platform behavior.

Workaround: locally adding "type": ["string", "number", "integer", "boolean", "object", "array", "null"] to the two fields lets base44 dev start normally. That isn't a good permanent fix, because the entity file is owned by the Builder and changing it would change the production schema on the next publish.