Add correct type filters when redirects /issues url

MR: Fix issues page redirect param (!211911 - merged)

As a part of Redirect from issues and epics route to work it... (#513115 - closed), we added ?type=issue filter when accessing issues list to be redirected to work items list.

This would lead to regression for all use cases where the user wants to see current issues, tasks and incidents as on prod.

According to the latest discussion on slack,

Expectation

redirecting /epics with type=epic and redirecting /issues with type!=epic to match user expectations

Used slack AI for summarizing ⏬

Deepika raised a question about the intended redirect from the /issues page to the /work_items page with the type=issue parameter, and whether there are plans to add the work items URL to the metadata API.

• Matt noted that the redirect for group issues was recently introduced, and suggested using type != epic to show everything that isn't an epic in the list on the redirect
• Kassio suggested using the WorkItems::Type.allowed_types_for_issues list instead, which includes "issue", "incident", "test_case", "requirement", "task", "ticket" 1(https://gitlab.enterprise.slack.com/archives/C08TMFMAE10/p1762421816532849?thread_ts=1762397805.584579)
• Vlad wondered if the type filter is needed at all, and suggested moving towards "all work items are similar" 2(https://gitlab.enterprise.slack.com/archives/C08TMFMAE10/p1762431787913769?thread_ts=1762397805.584579)
• Nick suggested either using type != epic or removing the type filter entirely, and providing an informational message to users on the redirected page 3(https://gitlab.enterprise.slack.com/archives/C08TMFMAE10/p1762446788862229?thread_ts=1762397805.584579)
• Amanda recommended redirecting /epics with type=epic and redirecting /issues with type!=epic to match user expectations