openstack limit list --service passes service object instead of service UUID

Summary
-------
The openstack limit list --service <service> command fails with a 400 BadRequest when filtering unified limits by service.

The client appears to pass the full service resource object instead of only the service UUID as service_id when calling the Keystone unified limits API.

Environment
-----------
OpenStack release: 2026.1 / Gazpacho-based
python-openstackclient version: 9.x
Keystone unified limits API enabled

Steps to Reproduce
------------------
1. Source OpenStack admin credentials:

   source admin-openrc

2. Run the unified limits list command filtered by service:

   openstack limit list --service keystone

Expected Result
---------------
The command should complete successfully.

If no unified limits are configured, it should return an empty list.

If limits are configured for the requested service, it should return the limits filtered by that service.

Actual Result
-------------
The command fails with a 400 BadRequest from Keystone.

Example error:

   BadRequestException: 400: Client Error for url:
   http://<keystone-endpoint>/v3/limits?service_id=description&service_id=is_enabled&service_id=links&service_id=name&service_id=type&service_id=id&service_id=location,
   Invalid input for field/attribute service_id. Value: description. 'description' is not a 'uuid'

The request URL shows that multiple service_id query parameters are generated from fields of the service object instead of using the service UUID.

Reproducibility
---------------
Reproducible

The issue is observed when running:

   openstack limit list --service keystone

with python-openstackclient 9.x.

Impact
------
Unified limits listing by service is broken in the OpenStack CLI.

This affects users and validation workflows that need to list registered limits or project limits filtered by service.

The system remains otherwise usable, but this specific CLI workflow fails.

Relevant Error
--------------
The generated Keystone API request contains invalid service_id values:

   service_id=description
   service_id=is_enabled
   service_id=links
   service_id=name
   service_id=type
   service_id=id
   service_id=location

Keystone expects service_id to be a UUID, not service object attribute names.

Root Cause / Analysis
---------------------
The issue appears to be in python-openstackclient identity v3 limit list handling.

In:

   openstackclient/identity/v3/limit.py

the ListLimit command appears to assign the result of the service lookup directly to service_id.

Conceptually, the problematic behavior is:

   kwargs["service_id"] = common_utils.find_service_sdk(
       identity_client, parsed_args.service
   )

This passes the full service resource object to the SDK request path.

The expected behavior is to pass only the resolved service UUID:

   kwargs["service_id"] = common_utils.find_service_sdk(
       identity_client, parsed_args.service
   ).id

The create limit path appears to use the service object's id field correctly. The list limit path should behave consistently.

Suggested Fix
-------------
Update the ListLimit command handling in:

   openstackclient/identity/v3/limit.py

so that the --service argument resolves to the service resource id before being assigned to service_id.

Expected correction:

   service_id should be set to the resolved service resource id, not to the full service resource object.

After the fix, this command should complete successfully:

   openstack limit list --service keystone

The generated Keystone API request should contain a single service_id query parameter whose value is the UUID of the requested service.

Workaround
----------
No workaround is currently known for using the --service filter.

If applicable, unified limits can still be listed without filtering by service:

   openstack limit list