fix(authz-casdoor): scope session cookie per Casdoor client

[shreemaan-abhishek]

Description

Each route configured with the authz-casdoor plugin now stores its session under a cookie name derived from its client_id, and the session payload itself is bound to the client_id it was issued for.

Previously, every authz-casdoor route on a given host shared the default resty.session cookie name (session), and the access check at the start of _M.access only verified that an access_token was present in the session — it did not verify that the session belonged to the route's client_id. As a result, two authz-casdoor routes on the same host configured with different client_ids shared authentication state.

The fix has two layers:

1. Per-client cookie name. A cookie name is derived from conf.client_id (sanitized to [A-Za-z0-9_]) and passed as cookie_name to every resty.session open / new / start call inside the plugin. Different client_ids now read and write different cookies.
2. In-session client_id binding. client_id is stored in the session at write time. The gate check additionally requires session_obj:get("client_id") == conf.client_id before honoring an existing session, so a session payload cannot be honored by a route configured with a different client_id.

A regression test (TEST 11 + TEST 12 in t/plugin/authz-casdoor.t) configures two routes on the same host with different client_ids (low-client on /low/*, high-client on /high/*), drives the full login flow against the first route, and then re-uses the resulting cookie against the second route — asserting that the second route still redirects to Casdoor with its own client_id.

Which issue(s) this PR fixes:

Fixes #

Breaking changes

1. After upgrading, existing authz-casdoor sessions will not be recognized: the cookie name changes from the resty.session default to a per-client_id name. Users will be redirected to Casdoor once to re-establish their session.
2. Deployments that had two authz-casdoor routes on the same host with different client_ids and implicitly relied on a single session being shared between them will no longer do so. Operators that want shared authentication state across routes should configure those routes with the same client_id.

Checklist

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change
• I have updated the documentation to reflect this change
• I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)