CI: Newman job red — openbuilt register not seeded on app:enable; tests/integration needs OR lifecycle ref + seed command

[rubenvdlinde]

Spun out of #28 (which fixed the PHPUnit half of #11 + the #19 transition-endpoint collection change).

Symptoms

The quality / Integration Tests (Newman) job fails: every assertion in tests/integration/*.postman_collection.json fails (including the pre-existing GET hello-world manifest returns 200). Job log shows:

OpenBuilt: SeedHelloWorld failed — DoesNotExistException: ... SELECT * FROM oc_openregister_registers WHERE LOWER(slug) = 'openbuilt'
Exception while executing repair step Seed Conduction-curated OpenBuilt ApplicationTemplate records — Failed to seed template "permit-tracker": ... oc_openregister_registers WHERE slug = 'openbuilt'
... and at request time: getManifest failed for slug hello-world — DoesNotExistException: ... oc_openregister_registers

Root cause

OpenBuilt's <install> repair steps run on occ app:enable openbuilt, in order InitializeSettings → SeedHelloWorld → PopulateApplicationPermissions → SeedApplicationTemplates. InitializeSettings is supposed to import lib/Settings/openbuilt_register.json via OpenRegister's ConfigurationService and thereby create the openbuilt register — but against the OpenRegister version CI installs (additional-apps: ref:main) it does not, so the register never exists and every subsequent step / API call that resolves register=openbuilt fails.

Contributing factors:

• code-quality.yml pins OpenRegister to main, which is stale ("overwritten with beta 2") and predates the lifecycle/transition feature OpenBuilt's versioning code depends on (ObjectTransitionedEvent, ObjectService::searchObjectsBySlug, POST /api/objects/{id}/transition, the x-openregister-lifecycle schema annotation). Those live only on OpenRegister development.
• OpenRegister development HEAD currently fatal-errors at app-enable (Cannot redeclare OCA\OpenRegister\Db\Organisation::$mail — regression from openregister#1494), so it isn't a usable pin right now either.
• The Newman job runs with an empty newman-seed-command, so there's no explicit occ maintenance:repair fallback to (re)seed the register.

Suggested fix

1. Diagnose why InitializeSettings → ConfigurationService::importFromApp('openbuilt', …) doesn't create the register against the pinned OR (likely an OR-API mismatch; may resolve once OR is pinned to a ref with the lifecycle feature).
2. Once OpenRegister development is healthy again, bump additional-apps to track it (the active OR integration branch, the same target OpenBuilt's own PRs use).
3. Consider setting newman-seed-command: php occ maintenance:repair in code-quality.yml so the register/schemas/seed data are guaranteed present before Newman runs.
4. File openregister#NNNN for the Organisation::$mail redeclare regression on development.

Until then, the new POST .../transition step in tests/integration/openbuilt.postman_collection.json (added in #28) is correct but can't pass — it needs OR's lifecycle feature + a seeded register.

[rubenvdlinde]

Root cause fixed:

• The openbuilt register was failing to be created at occ app:enable because OpenRegister main (what the CI installed) predates the auto-create-Register-on-application-import fix (OR PR #1464). OpenBuilt's CI now installs OR development (PR ci: install OpenRegister development (runtime-schema-API + lifecycle) — closes #29 #30), which has #1464 + the lifecycle engine. The blocking Cannot redeclare OCA\OpenRegister\Db\Organisation::$mail regression on OR development was fixed in OR PR #1499.
• Verified in the latest CI Newman run: OR development enables cleanly (openregister 0.2.13-unstable.80 enabled), occ app:enable openbuilt runs, and GET .../objects/openbuilt/application?_filter[slug]=hello-world returns 200 — i.e. the register + seeded hello-world app exist.

The Newman job is still red, but for unrelated collection bugs now (not a setup/register problem): several chain collections have unsubstituted {{app_uuid}}/{{created_uuid}} path vars (variable-extraction step not firing), the export collection uses the schema slug exportJob instead of export-job, and the export "submit → 202" step doesn't get a 202. Split out to a fresh issue.