ExportService::buildScaffoldMap() has no production caller — its call site was never rescued from Codeberg

[rubenvdlinde]

ExportService::buildScaffoldMap() was rescued from Codeberg in #117. Its call site was not, so on GitHub the method is currently dead: nothing in lib/ calls it.

Measured on origin/development @ 4115de22f:

git grep -n buildScaffoldMap -- lib/     # only the definition in ExportService.php

On codeberg/development the caller exists:

codeberg/development:lib/Service/GitHubAppSyncService.php:294:
    $scaffold = $this->exportService->buildScaffoldMap(context: $context);

It is GitHubAppSyncService::scaffoldFor() (a private helper, ~75 lines with slugToNamespace() / slugToLabel()), folded into push():

$files = array_merge(
    $this->scaffoldFor(application: $application, version: $version),
    $this->serializer->serialize(application: $application, version: $version)
);

Why it was not included in #117

It is not a file copy. GitHub's GitHubAppSyncService has diverged and is strictly newer than Codeberg's on that file (85 insertions / 55 deletions between the two tips). GitHub has, and Codeberg lacks:

• the AppChannelApplier constructor dependency + the channels result of pull() (apply-v2-channels)
• OUTCOME_FORBIDDEN and the 403-is-a-permissions-answer branch
• the warning-level broker diagnostics (Codeberg still logs those at debug)

Taking Codeberg's blob would revert all three. The port has to be a deliberate change: add ExportService as an additional constructor dependency (watch CouplingBetweenObjects — the class would go to 9 collaborators), add scaffoldFor(), fold it into push(), and cover it with a test that asserts the published file map carries both the scaffold and the config triad, with config winning on a path collision.

Until then

buildScaffoldMap() stays public in ExportService as a designed-but-unwired entry point — not because a test needs to reach it (see #117, which made the other nine methods private for exactly that reason). Its docblock says so.

Depends on: #117