In order to be affected by Turpentine (or the module you use) layout, you'd place your block in layout files also, not as a content loaded in CMS (or custom layout in backoffice) entities
update
Instead of loading your block in a CMS block, page, etc... or a Custom Layout update in backoffice you'd place it in the relevant layout file in app/design/frontend
For instance, as a generic example: let's say you want your block to be rendered in checkout/cart page
Edit your app/desing/frontend/XXX/XXX/checkout.xml file & define your block inside checkout_cart_index content tag
<checkout_cart_index translate="label">
...
<reference name="content">
...
<block type="core/template" name="supplier.delivery" as="supplier.delivery" template="myphp/delivery.phtml" />
You'd then load your block in checkout/cart.phtml template, calling echo $this->getChildHtml('supplier.delivery');
Then, open your app/design/frontend/XXX/XXX/turpentine_esi.xml layout file, and add your code there
<reference name="supplier.delivery">
<action method="setEsiOptions">
<params>
<scope>page</scope>
<registry_keys>
<current_category/>
</registry_keys>
</params>
</action>
</reference>
It's not required to use turpentine layout file to place your code, but it is safer, as Magento loads layout files in some order, so it is possible that ESI definition won't work if you use a different file than the provided by the module
I mean, technically you could add Turpentine methods directly in your block definition...
<block type="core/template" name="supplier.delivery" as="supplier.delivery" template="myphp/delivery.phtml">
<action method="setEsiOptions">
<params>
<scope>page</scope>
<registry_keys>
<current_category/>
</registry_keys>
</params>
</action>
</block>
But this could work, or not... so it is better to use the long approach