Centralize application registration

[itsDNNS]

Summary

• centralize core, built-in, and community contributions behind one deterministic registration plan and registrar
• preflight routes, assets, templates, configuration ownership, secrets, i18n, themes, thresholds, collectors, and publishers before applying the plan
• reject incomplete or colliding module plans without partial application, while preserving disabled community theme previews as validated metadata
• align production and test application creation with the same startup contract and document the contributor-facing rules
• emit a stable, redacted registration manifest fingerprint for startup diagnostics

Compatibility

• preserved the implementation-base registration surface: 143 routes, 21 blueprints, and 28 built-in modules
• retained manifest v1, endpoint names, URL paths, module identifiers, and existing community fixture contracts
• retained deterministic first-source handling for duplicate community IDs and warning-only template basename conflicts

Checks

• python -m pytest tests/ -v --tb=short --ignore=tests/e2e (3,860 passed, 2 skipped)
• focused module, security, prefix, PWA, report, factory, and architecture suites (303 passed)
• targeted Chromium issue gate (54 passed)
• full Chromium E2E (531 passed)
• npm test (9 passed)
• python scripts/i18n_check.py --validate
• registration payload equivalence and fresh-process fingerprint determinism
• git diff --check