Document that unlicensed instances accept one assignee_username

What does this MR do and why?

This MR adds "Instances without a license accept only one username." to the assignee_username description of the merge request list endpoints, because CheckAssigneesCount accepts a single value unless the license includes multiple_issue_assignees, which every plan does, Starter included.

!269726 (merged) has since fixed the rest of this description on master, which now says "assigned to the given usernames" instead of "created by the given username", so after the rebase onto master this sentence is all that is left. doc/api/openapi/openapi_v3.yaml is regenerated, and no behavior changes.

References

• The sentence comes from GitLab Duo's review of this MR, which found that a legacy Starter license also accepts several usernames: !266340 (comment 4118896813)
• I found this while working on the merge request list filters of gitlab-mcp-server, which keeps a record of its upstream work in upstream-bugs.md.

Screenshots or screen recordings

Before	After
Returns merge requests assigned to the given usernames.	Returns merge requests assigned to the given usernames. Instances without a license accept only one username.

How to set up and validate locally

1. Open doc/api/openapi/openapi_v3.yaml and find the assignee_username and not[assignee_username] parameters of GET /merge_requests, GET /groups/:id/merge_requests, GET /projects/:id/merge_requests and GET /projects/:id/deployments/:deployment_id/merge_requests: all eight carry the new sentence.
2. On an instance without a license, pass two assignee_username[] values to GET /api/v4/projects/:id/merge_requests: the request is refused with 400, "allows one value, but found 2".

How I checked it

On master de7a542ac534, this change makes bin/rake gitlab:openapi:v3:generate rewrite exactly these eight descriptions. Locally the task also swaps sec and mr_diff in the database names of the admin migration endpoints, with or without this change: that order follows config/database.yml, which here lists no sec database while CI's does, so the committed file keeps master's order, and gitlab:openapi:v3:check_docs reports only that swap, on master as well. RuboCop on the helper reports no offenses, scripts/lint/commit_linter.rb passes the commit, and the issue list specs that exercise CheckAssigneesCount pass: one value without a license, several with one.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

---