[Operability/Supply chain] Remove fake Config Server Git fallback from supported runtime

[seonghobae]

Buyer / operator gap

Protected develop@622e5e6c3d534f230c390f10e3832efadfc01825 contains a real Spring Cloud Config Server module (@EnableConfigServer) whose Git backend defaults to a placeholder remote repository:

spring:
  cloud:
    config:
      server:
        git:
          uri: ${CONFIG_REPO_URI:https://github.com/your-repo/config-repo.git}

The protected README labels Config Server Future and the documented normal service-start order omits it. The default Docker Compose profile also omits Config Server. However protected .replit still launches the Config Server JAR without setting CONFIG_REPO_URI; active runtime-supply-chain PR #169 continues to launch that service while repairing separate Zipkin/start-authority defects.

This creates an ambiguous production/developer runtime boundary: an explicitly future/unsupported component can attempt a mutable external Git fetch from a fake placeholder URL rather than fail closed on missing deployment configuration or remain absent from the supported topology.

RCA

• Immediate cause: CONFIG_REPO_URI has a syntactically valid but non-real placeholder network default.
• Technical root cause: Config Server lifecycle/ownership is not consistently classified across README, Docker Compose, Replit runtime, and Spring configuration.
• Control failure: no deterministic contract requires unsupported/future components to stay out of supported startup surfaces or requires Config Server to have an explicit approved repository URI before network access.
• Supply-chain/SSRF-adjacent concern: allowing a default remote Git URI makes network destination authority implicit. The placeholder domain is not a trusted configuration source and must never become a production fallback merely because it parses as HTTPS.

Distinct remediation options / feasibility

1. Preferred if Config Server remains Future — remove it from supported runtime launch surfaces. After fix(supply-chain): retire unsafe Replit Zipkin bootstrap #169's .replit branch is stable, stop launching Config Server from the default Replit topology. Keep the module buildable/reference-only until a separately accepted configuration-service contract exists.
2. Alternative if Config Server is promoted to supported — fail closed without explicit CONFIG_REPO_URI. Remove the placeholder fallback, document allowed source/auth/TLS/egress/refresh semantics, and prove an approved configuration repository through deterministic tests and an operator-controlled integration environment.
3. Reject: replacing your-repo with another guessed repository; adding a secret because the placeholder exists; keeping a mutable unauthenticated/unverified network fallback; or claiming Config Server support from module compilation alone.

Source mutation is defer_until_trigger while #169 actively owns .replit and #149 owns canonical runtime documentation. This issue does not authorize racing either branch.

Acceptance

• canonical PRD/TRD/Architecture/Operability/Traceability classifies Config Server truthfully as supported, planned/reference-only, or removed;
• a Future/reference-only Config Server is not launched by default Compose/Replit/operator startup paths;
• a supported Config Server has no fake/default external Git destination and fails closed before remote access when required configuration is missing;
• any supported remote config source has explicit destination/TLS/auth/credential provenance, bounded timeout/retry/refresh behavior, and secret-safe diagnostics;
• tests prevent https://github.com/your-repo/... or equivalent demo placeholder from reappearing in production configuration;
• startup/degraded-mode documentation explains behavior when the config repository is unavailable;
• no cross-repository mutation or invented credential is required;
• exact source/security/coverage/review evidence is regenerated after implementation.

This issue is complementary to #168/#169 (repository runtime supply-chain cleanup), #178 (effective JDK runtime proof), and #165 (release/provenance).

[seonghobae]

Execution update — path-disjoint fail-closed slice opened as Draft PR #189 from exact protected develop@622e5e6c3d534f230c390f10e3832efadfc01825.

Exact fail-first head: d0f2931580fa7db00355d9209a50ba9bac768b0e.

The branch changes only a Config Server repository-authority contract test first. It requires spring.cloud.config.server.git.uri to be exactly ${CONFIG_REPO_URI} with no demo/HTTPS fallback and rejects your-repo/config-repo.git. This narrows the earlier over-broad defer_until_trigger: .replit removal remains owned by #169 and canonical runtime classification remains owned by #149/#159, but eliminating the fake Git fallback in config-server/src/main/resources/application.yml is path-disjoint and valid under either terminal product decision (reference-only Config Server or explicitly supported Config Server).

No repository URI, credential, network exception, or support claim is invented. Hosted RED is required before the one-line production correction; queued checks are not counted as evidence.