fix: resolve compose project name from compose config

[bunnysayzz]

Fixes #842.

When two compose projects on the same daemon run a service with the same name, lazydocker bound the wrong project's container to the local service: shift-E shelled into the other project's container and the services tab showed the wrong name.

Root cause: LocalProjectName was inferred by scanning the daemon-wide container list and taking the project of the first container whose service name matched a local service name. With a same-named service in another project, list order picked the project and poisoned every local service binding.

The fix asks compose itself. GetServices now runs docker compose config --format json and takes the top-level name, which compose resolves the same way it does at runtime (-p, COMPOSE_PROJECT_NAME, the name: directive, then the directory name). The container-list scan is gone; the only fallback left is the directory name, which is compose's own last resort. Old docker-compose binaries without --format json fall back to config --services as before.

Tests: TestParseComposeConfigJSON (+ invalid and empty cases) and TestAssignContainersToServicesPicksOwnProject, which replays the issue's two-projects-one-service-name setup with the foreign container first in list order. go test ./pkg/commands/ passes, vet clean. No docker daemon here so the GUI path itself is untested, the parsing and binding logic is covered.