feat(lfc)!: support inline configuration service data in lifecycle.yaml

[vigneshrajsb]

Summary

Adds support for configuration services that declare their key/value data inline in lifecycle.yaml, instead of relying solely on the configurations DB table.

The data is materialized onto the per-build deployable.env via YamlService.getEnvironmentVariables (Option A), so it flows through the existing full-yaml env pipeline — the same path github/helm services already use. There is no redundant write-to-DB-then-read for YAML-defined config.

services:
  - name: app-config
    configuration:
      data:
        FEATURE_FLAG: "true"
        API_BASE: "https://api.example.com"
        DB_PASSWORD: "{{aws:my/secret/path}}"

Consuming services reference the keys normally ({{FEATURE_FLAG}}). External-secret refs ({{aws:...}}) resolve transitively through the consuming service's own deploy pipeline — config deploys are never built or deployed, so they are never scanned directly.

Changes

• schema_1_0_0: the configuration block now takes data (required, map of string→string) and optional branchName; defaultTag is removed. Regenerated 1.0.0.json + docs/schema/yaml/1.0.0.yaml accordingly (configuration block only).
• YamlService: CONFIGURATION case in getEnvironmentVariables returns configuration.data; ConfigurationService type updated.
• buildEnvVariables.resolve(): skips CONFIGURATION deploys so their (possibly secret-ref-bearing) data is never persisted as plaintext on the unused config deploy's env.
• envVariables.configurationServiceEnvironments: full-yaml sources deployable.env; classic (non-full-yaml) builds keep the configurations-table read. A YAML-defined config without a serviceId now warns in classic mode (no values logged) instead of being silently dropped.
• Removes the dead, superseded server/models/config module (no production importers; the live path uses server/models/yaml). Confirmed via static + dynamic import trace and an independent review pass.

Breaking change

Warning

The inline configuration block no longer accepts defaultTag and now requires a data map of string values. Existing inline configuration blocks using the old { defaultTag, branchName } shape will fail schema validation on next ingestion. Configs referenced by serviceId (classic mode) are unaffected. data values must be strings — quote scalars like PORT: "8080".

Testing

• Full suite: 217 suites / 2171 tests pass (the −1 suite vs. before is the deleted dead module's test).
• eslint clean on touched files; tsc --project tsconfig.server.json --noEmit: 0 errors.
• New configurationServiceEnvironments tests cover: full-yaml sources deployable.env (asserts the configurations table is not queried), classic reads the table by serviceId/branchName, and classic-without-serviceId resolves to empty without querying.

Notes

• Runtime validation uses the TS schema object (schema_1_0_0), not the generated JSON; the generated 1.0.0.json/docs YAML are editor/doc artifacts. The generator is additive-merge and has pre-existing drift unrelated to this change, so only the configuration block was corrected here to avoid sweeping in unrelated schema deltas.