[2.x] [Tags] Drop legacy unused background columns from tags table

[Abdooo2235]

Summary

This PR removes two legacy columns from the tags table that are no longer used by current tags flows:

• background_path
• background_mode

Fixes #4527.

What changed

• Added a safe, idempotent migration that drops both columns only when they exist.
• Added reversible down logic to restore the columns if needed.
• Removed stale references from the tag factory and model docblocks.
• Kept API compatibility by retaining backgroundUrl and backgroundMode attributes, now read via generic model attributes.
• Added an integration schema test asserting those columns are absent after migrations.

Backward compatibility

• Migration guards on hasTable and hasColumn to be safe for varied install states.
• Existing data in removed columns is dropped as part of schema cleanup.
• API keys remain available to reduce integration risk for consumers expecting these attributes.

Scope note

An unrelated local change in extensions/tags/js/tsconfig.json was intentionally excluded from this PR to keep the fix focused.

Testing

• Added: extensions/tags/tests/integration/api/tags/SchemaTest.php
• Local test execution in this environment is blocked because phpunit is not available (sh: 1: phpunit: not found).

[DavideIadeluca]

Thanks for picking up the issue I opened. Have you considered using Flarum’s migration helper? The migration in the PR feels a bit more complex than necessary and could likely be simplified along these lines:

use Flarum\Database\Migration;

return Migration::dropColumns('tags', [
    'background_path' => [..],
    'background_mode' => [..],
]);

Note that with Migration::dropColumns() you still need to specify the column constraints and metadata, similar to what you would define in the up migration.

Another thing that stood out in the PR is that the attributes are still present. If background_mode and background_path are no longer required, wouldn’t this effectively become dead code? It might be better to remove them entirely and go for a clean break.

Since Flarum 2 hasn’t been tagged as stable yet, a breaking change like this should still be acceptable without creating backwards compatibility concerns.