Harden calendar trashed-message Undo URL construction

[GaryJones]

Summary

The calendar view renders a "post moved to the trash" notice with an Undo link when the admin arrives with ?trashed=N&ids=... in the URL. That notice was built by interpolating the raw \$_GET['ids'] value straight into the link's href, deriving the post type from the first comma-separated value, and leaning on esc_url() to make the result safe.

esc_url() only makes a URL safe to emit into HTML — it escapes the ampersand for HTML context so that reading the href in the source shows &, but it does not URL-encode values inside the query string. A crafted request like ?trashed=1&ids=1%26action%3Dmalicious would therefore produce an Undo link whose query string contained an injected action=malicious parameter alongside ids=1. The post type, read from the first value in the list with no validation, could similarly be any arbitrary string.

The fix pushes every id through absint(), reassembles the list from the resulting integers, and only proceeds when post_type_exists() confirms the derived post type is real. The URL itself is then built with add_query_arg() so the & separator can never originate from user input. As tidying whilst in the file, the count values for both branches are cast to int once and reused, a stray unset( \$_GET['undeleted'] ) is corrected to the parameter the branch actually guards on (untrashed), and the ValidatedSanitizedInput phpcs suppression is dropped now that sanitisation happens in code rather than by comment.

Test plan

• Trash a post from the calendar view; confirm the "moved to the trash" notice renders with a working Undo link
• Manually append &ids=1%26action%3Dmalicious to a ?trashed=1 calendar URL and confirm the rendered Undo link carries only a clean ids=1 value and a registered post type
• Untrash from the Undo link and confirm the "restored from the Trash" notice renders correctly