fix(tags): deleting a tag orphans every use/application of it

[DocArmoryTech]

Deleting a tag leaves every tags_tagged row that referenced it behind,
pointing at an id that no longer exists.

Why

TagsTable::initialize() declares no association to Tagged:

public function initialize(array $config): void
{
    $this->setTable('tags_tags');
    $this->setDisplayField('name');
    $this->addBehavior('Timestamp');
}

No hasMany, no dependent => true, and tags_tagged.tag_id carries no
foreign key. Tags::delete therefore removes the tags_tags row and nothing
touches the taggings.

The orphans are invisible rather than just stale. Every query that resolves a tagging joins tags_tags, so the rows disappear from counts while still occupying the unique index on (tag_id, fk_id, fk_model).
tags_tags.counter, maintained by the CounterCache that TagBehavior::attachCounters() attaches, is equally blind to them.

Changes

• TagsTable: add hasMany('Tagged', [... 'dependent' => true, 'cascadeCallbacks' => true]). cascadeCallbacks keeps the delete going through the ORM rather than a bulk query.
• New migration pruning rows orphaned before the association existed, and rebuilding tags_tags.counter afterwards since a raw DELETE bypasses the CounterCache. Any instance that has ever deleted a tag has these.

Notes

The migration is a no-op where there is nothing to prune, and is not reversible i.e. the rows referenced tags that no longer exist, so there is nothing to restore them to.

An alternative to the association is a foreign key on tags_tagged.tag_id with ON DELETE CASCADE. It is cheaper but bypasses the behaviour layer, so I went with the association.

Verifying

SELECT COUNT(*) FROM tags_tagged tg
WHERE NOT EXISTS (SELECT 1 FROM tags_tags t WHERE t.id = tg.tag_id);

Non-zero before the migration on any instance that has deleted a tag; zero after. Creating a tag, applying it, then deleting it should leave no residue.