Fix backend logging to report actual backend and auto-set Docker profile

[Copilot]

lock_backend in canonical logs always reported "memory" due to @Value("${lock.backend:memory}") defaulting when unset. Docker images required manual SPRING_PROFILES_ACTIVE despite backend being determined at build time.

Changes

Backend name from interface

• Added getBackendName() to LockService interface
• Each implementation returns its identifier: memory, firestore, etcd, dynamodb, postgres
• LockManagerService now calls lockService.getBackendName() instead of reading a property

// Before
@Value("${lock.backend:memory}")
private String lockBackend;

// After
context.put("lock_backend", lockService.getBackendName());

Docker auto-profile

• Dockerfile now sets ENV SPRING_PROFILES_ACTIVE=${LOCKER} from build arg
• Containers no longer require manual profile configuration

Testing

• Added getExpectedBackendName() abstract method to AbstractLockServiceTest
• New test verifies each backend returns correct name

Original prompt

The backend being logged is always logging memory

    @Value("${lock.backend:memory}")
    private String lockBackend;

As you can see above it is pulling it from a value in:
api/src/main/java/com/unitvectory/lockservicecentral/api/service/LockManagerService.java

The thing is this shouldn't be set this way at all. The running application can only have one backend configured and that must be configured exactly one way.

Now the intent is for that to be configured at compile time so a separate JAR is compiled for each implementation. However, that isn't super elegant. That requires setting SPRING_PROFILES_ACTIVE

The two issues with this current implementation are the docker image when it is running just needs to have this SPRING_PROFILES_ACTIVE set to the approprate value to avoid needing to have that be set since it is always going to be that and the arg can be used.

And separately the logging needs to be correct for the Canonical Logging so which backend is used is logged properly with each request.

There may be a better way to handle this overal but the issue is the "everything" build also needs to work for testing so having profiles is the compromise.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.