fix(export): resolve agent register/schema by slug, not hardcoded numeric id

[rubenvdlinde]

Summary

FlowAndAgentExportBundler::bundleAgents() filtered agents by two hardcoded
numeric class constants — OPENBUILD_REGISTER = 206, AGENT_SCHEMA = 5060,
this dev instance's auto-increment ids for the openbuild register and
agent schema. Those ids are not stable across a fresh install: on any
instance where they land differently, the findAll() filter silently
matches zero rows — no exception, no skip record, just an export that
reports succeeded having bundled nothing.

This was confirmed live today: app-repo-format-flow-agent-export (#255,
merged today) wired this same method into the buildiq-* GitHub round trip,
and its live round-trip test on a fresh instance hit exactly this failure
mode.

• Replaced the two numeric constants with the slugs 'openbuild'/'agent',
  mirroring the pattern already used by AgentsController,
  ObjectSchemaSlugResolver, and AppChannelApplier::credentialExists().
  ObjectService::findAll() already resolves a string filter value through
  RegisterMapper/SchemaMapper, which support slug lookup — no new
  collaborator, no constructor change, no call-site change beyond the two
  constants.
• Extended FlowAndAgentExportBundlerTest to assert the findAll() filter
  now carries the slugs, guarding this exact regression.
• bundleFlows() (already UUID-based) and every caller
  (AppRepoSerializer/AppChannelApplier/FlowAgentChannelCollector) are
  untouched — both of OpenBuild's export systems share this method and both
  inherit the fix.
• OpenSpec: added bundle-agents-slug-not-numeric-id, archived, folded a new
  requirement into the openbuild-exporter canonical spec.

Live verification (not just unit tests)

Spun up an isolated docker-compose instance (project g19bai, its own
containers/ports/volumes, torn down afterward — docker ps before/after is
identical, no other session's containers touched) with openregister +
openconnector + openbuild (this branch) + hermiq. Created a test
Application + Agent, then ran the full round trip including a negative
control:

step	register/schema ids on this fresh instance	agent bundled?
Fixed code	openbuild=16, agent=115 (a second, unrelated agent schema id=87 also exists on this instance — schema slugs are not globally unique, confirming the register-scoped resolution matters)	YES
Reverted to old hardcoded 206/5060 (neither id exists on this instance)	n/a	NO — export still reported succeeded, zero agent files in the ZIP — the exact silent-failure mode from the bug report, reproduced live
Fix restored	same as row 1	YES again

Test plan

• FlowAndAgentExportBundlerTest: 6/6 green, including the new
  slug-filter assertion
• Full unit suite: 865 tests / 2643 assertions, 8 pre-existing
  ZipArchive-missing errors unrelated to this change (host PHP has no
  zip extension; reproduced identically against the unmodified
  apps-extra/openbuild checkout)
• phpcs/phpmd/phpstan/psalm clean on the changed file (the file's
  one pre-existing PHPCS warning is unchanged before/after this diff)
• Live docker-compose round trip on a fresh instance, including the
  negative control above

[github-actions]

Quality Report — ConductionNL/openbuild @ 4bd6d10

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
test-l10n		✅
check-gitignore		✅
check-nc-floor		✅
format		✅
composer			✅	✅ 106/106
npm			✅	✅ 626/626
app:check-code	⏭️
info.xml	✅
REUSE	❌
PHPUnit					✅
Newman					✅
Playwright					❌
Hydra gates					✅

---

Quality workflow — 2026-08-19 09:14 UTC

Download the full PDF report from the workflow artifacts.

[github-actions]

Quality Report — ConductionNL/openbuild @ 4bd6d10

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
test-l10n		✅
check-gitignore		✅
check-nc-floor		✅
format		✅
composer			✅	✅ 106/106
npm			✅	✅ 626/626
app:check-code	⏭️
info.xml	✅
REUSE	❌
PHPUnit					✅
Newman					✅
Playwright					✅
Hydra gates					✅

---

Quality workflow — 2026-08-19 10:25 UTC

Download the full PDF report from the workflow artifacts.