Content Creation: Abstract shared post preparation and validation

[johnjamesjacoby]

The front-end forum, topic, and reply handlers each combine request parsing, field normalization, validation, persistence, bookkeeping, hooks, and redirects. This makes their useful preparation and validation logic difficult to reuse safely from alternate entry points.

Recent hardening in [7511] and [7512] demonstrates the maintenance cost. bbp_move_reply_handler() and bbp_split_topic_handler() convert an existing reply into a topic, so they cannot call bbp_new_topic_handler() without creating another post and firing the wrong lifecycle effects. As a result, those paths had independently reproduced only part of the normal topic pipeline and had omitted its title filter and validation. Forums and replies have similarly self-contained new/edit handlers, and integrations or future alternate workflows can drift for the same reason.

We should extract side-effect-free preparation and validation code that can be reused across forum, topic, and reply operations while keeping request orchestration and persistence in their existing handlers.

The design should:

• preserve existing public filters, actions, accepted arguments, error codes, and compatibility behavior;
• separate request parsing from normalization, validation, persistence, bookkeeping, and redirects;
• support new, edit, conversion, REST, XML-RPC, and other applicable entry points without forcing them through front-end form handlers;
• make the checks required by each operation explicit, particularly content, title, parent/forum, status, capabilities, flooding, duplication, and moderation;
• avoid silently applying new-topic side effects to longstanding move and split workflows; and
• add parity tests for anonymous, participant, moderator, and restricted-content cases.

This is a follow-up architectural improvement rather than part of the narrow hardening change in [7511]. It can be staged by post type or validation concern rather than introduced as one oversized helper.