Feature/keycloak auth configuration

[JulienLouisSchneider]

Summary

This PR aligns the customer service with the Keycloak-based authentication architecture by removing duplicated identity fields from the local user model and replacing them with a company membership
representation. Users are now stored as user_companies records containing a Keycloak user identifier (id_auth_kc) and a business role.

Rationale

Keycloak should remain the single source of truth for authentication and identity, while this service should only manage business data such as company membership and role assignment. This change reduces
duplication, avoids storing identity data unnecessarily in the customer-service database, and better separates authentication concerns from domain logic.

Changes

• Reworked the user domain model to store id_auth_kc and role instead of first_name, last_name, email, and phone
• Renamed persistence from users to user_companies
• Updated SQL schema and seed data to reflect the new membership-based model
• Updated API routes from /users to /users-company
• Updated repository logic, tests, README examples, and API test script to use the new model and routes
• Improved configuration loading so missing required environment variables return explicit errors
• Injected app config into Gin context for route-level access
• Added configuration unit tests
• Adjusted Docker/Postgres local setup (5434 port and DB healthcheck)

Impact

This PR introduces breaking API and database changes:

• Endpoints using /users now use /users-company
• Existing users table assumptions no longer apply; the service now expects user_companies
• Request and response payloads for user-related operations now use id_auth_kc and role
• Any client, script, or integration using the previous user shape must be updated

Testing

Automated testing:

• bash test/test_api.sh

Additional Notes

This PR is primarily an architectural alignment step toward Keycloak integration. It does not yet implement JWT validation or Keycloak Admin API flows; it prepares the data model and service boundaries so
those additions can be built cleanly.

[dieperid]

LGTM