Fix: Use migration stubs and avoid duplicate migrations on republish

[scottgrayson]

Details

This PR fixes how the package handles migrations so it follows Spatie conventions and avoids duplicate migration files when users republish.

Problem

• Migrations were stored as timestamped .php files (e.g. 2024_01_01_000000_create_library_items_table.php) and were not marked as stubs.
• The package publishes migrations (copies them into the app); it does not load/run them from vendor.
• Spatie's ProcessMigrations strips any timestamp from migration names and adds the current date when publishing, so the 2024 timestamps in the repo were never used.
• Because getMigrations() used timestamped names, the "existing file" check looked for app files ending with 2024_01_01_.... Published files get a current timestamp, so the check never matched and republishing could create duplicate migration files.

Solution

• Convert migrations to stubs (no timestamps in repo): create_library_items_table.php.stub, create_library_item_permissions_table.php.stub, create_library_item_tags_table.php.stub, create_library_item_favorites_table.php.stub.
• Update getMigrations() to return the stub base names so the "already published?" logic works and republishing reuses the same files.
• Update tests: TestCase now runs the real flow (publish then migrate) instead of including migrations by path, so all four migrations run in order and tests match real usage.

Made with Cursor