Correct ICS text escaping per RFC 5545

[GaryJones]

Summary

The calendar module's ICS subscription feed had three long-standing escaping bugs that could produce invalid .ics output for any event text containing common punctuation or user-supplied content.

do_ics_escaping() replaced semicolons with backslash-colon rather than the RFC 5545 backslash-semicolon sequence, so any event text containing a semicolon produced an invalid escape. The same function escaped backslashes as its final step, which meant the backslashes it had just inserted whilst escaping commas and semicolons were themselves doubled on the second pass, corrupting the output for any string that contained those characters. Newlines were not escaped at all, so a stray LF in a post title, taxonomy term or metadata field would terminate the line and break every calendar client's parse of the remainder of the feed.

Two call sites in handle_ics_subscription() also bypassed the escaper entirely. The SUMMARY field concatenated the post status label directly, and the DESCRIPTION field concatenated the label and value of every information field without passing them through. Since taxonomy term names, custom status labels, and filter-supplied field values can all contain any of the special characters, the only safe option is to escape them.

The fix reorders do_ics_escaping() to match RFC 5545 section 3.3.11 (escape backslashes first, then newlines, then semicolons, then commas) and routes the previously-unescaped call sites through it. New tests pin the escaper's behaviour across each character class and their combination so any future regression is caught immediately.

Test plan

• composer test:integration — the new CalendarIcsEscapingTest cases pass
• Subscribe to a calendar that includes a post whose title contains a comma, semicolon, backslash or newline, and verify the resulting .ics feed parses cleanly in a calendar client