feat(github): add tag pattern filtering for deployments

[AHTOOOXA]

Why This Feature?

Problem: Teams using tag-based deployments currently have no control over which tags trigger deployments. Every single tag (test tags, RC tags, feature tags) triggers a deploy - causing unwanted deployments and wasted resources.

Real-world use cases this enables:

• 🏷️ Semantic versioning - Only deploy on v* tags, ignore test-* or dev-*
• 🚀 Release workflows - Deploy release-* to production, ignore rc-* candidates
• 📦 Monorepo support - Deploy only backend-v* tags for backend service, frontend-v* for frontend
• 🔒 Controlled rollouts - Only deploy prod-* tags, skip staging-* and hotfix-*

Example: A team pushing v1.0.0, v1.0.1-rc1, test-feature-x tags can now configure pattern v[0-9]* to only deploy final releases.

---

Summary

• Add ability to filter which tags trigger deployments using glob patterns
• Users can specify patterns like v*, release-*, v[0-9].* to selectively deploy
• Backwards compatible: empty patterns = deploy on any tag (existing behavior preserved)

Changes

Backend

• Add tagPatterns field to application and compose database schemas
• Add getGithubTags API endpoint to fetch repository tags via GitHub API
• Add apiFindGithubTags validation schema
• Update saveGithubProvider mutation to include tagPatterns
• Implement pattern matching in webhook handler using existing micromatch library
• Add try-catch around pattern matching for defensive error handling

Frontend

• Add "Tag Patterns" multi-select field in GitHub provider settings (shown when trigger type is "tag")
• Supports selecting existing tags from repository OR typing custom glob patterns
• Includes tooltip explaining glob pattern syntax
• Extract TagPatternsField as shared component (follows React hooks best practices)

Database Migration

• Adds tagPatterns column (text array, default empty) to both application and compose tables

Tests

• Add tagPatterns field to test fixtures

Backwards Compatibility

Existing applications configured to deploy on tags will continue to work unchanged:

• Empty tagPatterns (default) = deploys on ANY tag (same as before)
• Pattern check only runs when patterns are explicitly configured

Test plan

• Create application with GitHub source, set trigger type to "Tag"
• Verify "Tag Patterns" field appears with tooltip
• Test selecting existing tags from dropdown
• Test typing custom glob pattern (e.g., v*)
• Push a matching tag → verify deployment triggers
• Push a non-matching tag → verify deployment is skipped
• Test existing tag-triggered app still works (backwards compat)

🤖 Generated with Claude Code

[AHTOOOXA]

Hey @Siumauricio 👋 Would love to get your eyes on this when you have a moment! Just rebased onto latest canary to resolve the merge conflicts. Everything should be clean now.

[Alm0stEthical]

bump