fix: clear the snippet cache before new state is read back

[TallblokeUK]

Fixes #561.

Every write in snippet-ops.php cleared the cached snippet list as its last step, after the new state had already been read back and handed to the write's hooks. Anything reading in between was served the snippet as it stood before the write.

On a site with a persistent object cache this is visible to every user: saving an edited snippet returned the snippet as it was beforehand, and that value is what the REST update response is built from. Activating or deactivating reported the previous status. With file-based execution, the listener on each hook reads the snippet back, so a deactivated snippet was written to disk still marked active and went on running.

The cache is now cleared as soon as the database changes, before the snippet is read back and before any hook fires. Applied across save_snippet(), activate_snippet(), activate_snippets(), deactivate_snippet(), delete_snippet(), trash_snippet() and restore_snippet().

deactivate_snippet() also now passes the network flag when reading the snippet back, which it previously left to default.

Not covered here

The remaining part of the file-based execution report — no fallback to the database when the on-disk index is missing, and no rebuild outside of saving the settings page — is a separate change.

Verification

• New tests cover the returned value and the hook payload for saving, activating, deactivating and deleting. All seven fail without the change.
• Snippet creation was checked and is unaffected: a new identifier cannot be present in the cached list, so the read falls through to the database.
• Full PHPUnit suite (351 tests) and lint:php pass.
• Driven against a live site for saving, activating and deactivating, confirming the database and the returned snippet now agree.