謎が解けて来た。DBに実際に格納されてる文字列を見てみると、"post_content" と "post_content_filtered" と言う名前で2つテーブルが存在し、それぞれにほぼ同じ内容の文字列（投稿記事DATA）が格納保存されている。

最初は実際に表示されてる結果から、"post_content_filtered" の方がオリジナルDATAで、"post_content" の方は置換処理された後の補助的なDATAかと思っていたけども…どうも実際には逆で "post_content" の方がオリジナルで、"post_content_filtered" の方が補助的な位置付けらしい。と言うかテーブル名に「filtered」と有るからには、こっちの方がフィルタ処理された後のDATAなんだな。

恐らくはMarkDown記法はまだまだプラグイン的な位置付けあり、普遍的標準機能とは言い難いので、当面はMarkDown記法で記述されたオリジナル原文DATAの方を敢えて "post_content_filtered" の方へ保存し。本来はオリジナルDATAから生成された "filtered" であるはずのHTML化されたDATAの方を汎用オリジナルDATAとして "post_content" の方へ格納保存していると思われ…。

ある意味、処理負担を軽減させるためには正しいんだろうけども、原理原則に従うのならば "post_content" の中には一切の処理無しの原文ママの文字列を格納保存し、"post_content_filtered" の中にこそMarkDownなり記号置換処理なりを施した後の整形済みHTMLデータを保存して置き、それを必要に応じて使うべきだろう。その際、外部API等と通信する必要が有る埋め込み動画系のショートコードなども、事前にHTML化して保存して置くべきなのだろう。毎回、通信を行うのは生成コストが上がるので、事前生成して置きそれを使うのは、言うなれば簡易キャッシュ機能と言うべきか。

とりあえず投稿記事DATAを記事表示のタイミングでフックし、色々と文字列置換処理などを施す手法には慣れたと言うか把握したので。今後はDBを直にハックする分野へいよいよ踏み込もうと思う。1つ間違えばDB自体を破壊し、サイト全体をダウンさせる可能性も有るので少々緊張するけども、いつかは挑戦しなければならない分野。これを乗り換えれば確実にWordPress技術は上がるので、まずはローカル環境で色々と実験。

P.S.
という訳で気付けばもう12月。