[bug]: Work item advanced-search endpoint resolves as identifier route and search param mismatch

Current behavior

I’m seeing a reproducible API behavior gap in self-hosted Plane regarding work-item search/list endpoints used by API clients/MCP tools.

• POST /api/v1/workspaces/goodkind-io/work-items/advanced-search/ returns 403 Forbidden with {"detail":"You do not have permission to perform this action."}.
• GET /api/v1/workspaces/goodkind-io/work-items/search/?q=mwan returns 200 with an empty result set.
• GET /api/v1/workspaces/goodkind-io/work-items/search/?search=mwan returns matching issues as expected.

I verified URL resolution and route mapping behavior in the backend and observed that
/api/v1/workspaces/goodkind-io/work-items/advanced-search/ resolves to WorkspaceIssueAPIEndpoint with project_identifier='advanced' and issue_identifier='search', which appears to be a work-item-by-identifier route rather than the expected advanced search/list endpoint.

This causes clients that rely on filtered list paths to fail while unfiltered list calls still work.

• I have searched the existing issues

Steps to reproduce

1. Use a valid API token against a self-hosted Plane workspace (goodkind-io in my reproduction).
2. Confirm authenticated API access works.
3. Call:
   • POST /api/v1/workspaces/goodkind-io/work-items/advanced-search/ with a valid request context.
4. Observe 403 Forbidden and detail: You do not have permission to perform this action.
5. Call:
   • GET /api/v1/workspaces/goodkind-io/work-items/search/?q=mwan
6. Observe 200 with empty list response.
7. Call:
   • GET /api/v1/workspaces/goodkind-io/work-items/search/?search=mwan
8. Observe non-empty results.

Expected behavior

• The advanced-search path should route to a work-item search/list endpoint and return expected filtered results for API clients.
• Search APIs should return consistent behavior and documented query handling for query terms.
• Authenticated users with expected workspace/project access should not receive permission denied for the advanced search endpoint.

Environment

• Environment: Production
• Browser: N/a
• Variant: Self-hosted
• Version: 1.2.3

Additional context

• This is observed while using the upstream Plane API paths and an MCP client.
• get_me-style checks and unfiltered work-item list calls succeed; filtered behavior is where this fails.
• Sanitized evidence can be attached in follow-up if useful.

Start with the work-item URL mapping and WorkspaceIssueAPIEndpoint resolution described in the report, then trace the advanced-search and search paths with both q and search parameters. Reproduce the requests against a self-hosted workspace using valid authentication. Done means the advanced-search path reaches the intended search/list behavior, filtered requests return expected matches, and authorized users are not incorrectly denied.