perf: major speed up when querying jobs by tags

[michaeladler]

Description

Computing the total field in the /jobs pagination result parameter was done in a very inefficient way (correlating with the number of queried tags).

This patch series contains the following two optimizations:

1. Disable pagination metadata by default as this is typically only needed by UI clients. Clients relying on that information can append the new query parameter pagination=true to include the pagination metadata in responses.
2. The old ent-generated code looped over each tag and added a separate HasTagsWith predicate, producing one correlated IN subquery per tag:

  WHERE job.id IN (SELECT tag_jobs.job_id FROM tag_jobs
    JOIN tag ON ... WHERE tag.name = 'TAG1')
  AND job.id IN (SELECT tag_jobs.job_id FROM tag_jobs
    JOIN tag ON ... WHERE tag.name = 'TAG2')

Each subquery performs an independent scan of the tag_jobs table, which is expensive when the jobs table is large.

Replace this with a single explicit JOIN on tag_jobs and tags, filtering all requested tags in a single IN clause:

  FROM job
  JOIN tag_jobs ON job.id = tag_jobs.job_id
  JOIN tag ON tag_jobs.tag_id = tag.id
  WHERE tag.name IN ('TAG1', 'TAG2')

The JOIN allows the database to resolve the tag filter in a single pass.
Add a database index on tag_jobs(job_id) so the join can use an index lookup instead of a sequential scan.

Benchmarks

I used the enhanced wfx-loadtest to populate a locally running PostgreSQL database with 1 million jobs, each having two tags.

• wfx 0.5.0: Querying for one tag took approximately 3 seconds, while querying for two tags exceeded 10 seconds (hitting the wfxctl timeout).
• Optimized, with pagination enabled: Queries consistently took ~1 second, regardless of the number of tags.
• Optimized without pagination: Queries completed in ~25ms.

Issues Addressed

List and link all the issues addressed by this PR.

Change Type

Please select the relevant options:

• Bug fix (non-breaking change that resolves an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist

• I have read the CONTRIBUTING document.
• My changes adhere to the established code style, patterns, and best practices.
• I have added tests that demonstrate the effectiveness of my changes.
• I have updated the documentation accordingly (if applicable).
• I have added an entry in the CHANGELOG to document my changes (if applicable).

[codecov]

Codecov Report

❌ Patch coverage is 60.46512% with 34 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.73%. Comparing base (c06da84) to head (0d83d67).

Files with missing lines	Patch %	Lines
cmd/wfx/cmd/config/appconfig.go	7.69%	11 Missing and 1 partial ⚠️
internal/persistence/entgo/workflow_query.go	28.57%	9 Missing and 1 partial ⚠️
internal/server/server_collection.go	0.00%	5 Missing ⚠️
api/wfx.go	0.00%	4 Missing ⚠️
internal/persistence/entgo/job_query.go	89.28%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #429      +/-   ##
==========================================
- Coverage   73.90%   73.73%   -0.18%     
==========================================
  Files          96       96              
  Lines        4055     4059       +4     
==========================================
- Hits         2997     2993       -4     
- Misses        828      839      +11     
+ Partials      230      227       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.