feat(wupnext): add new env vars for mcp server

[javierlnmn]

What is this PR about?

Adds new env vars for MCP server + Django Q config missing ones.

Checklist

Before submitting this PR, please make sure that:

• I have read the suggestions in the README.md file https://github.com/Dokploy/templates?tab=readme-ov-file#general-requirements-when-creating-a-template
• I have tested the template in my instance, so the maintainers don't spend time trying to figure out what's wrong.
• I have added tests that demonstrate that my correction works or that my new feature works.

Issues related (if applicable)

Close automatically the related issues using the keywords: closes #ISSUE_NUMBER

Screenshots or Videos

[github-actions]

built with Refined Cloudflare Pages Action

⚡ Cloudflare Pages Deployment

Name	Status	Preview	Last Commit
templates	✅ Ready (View Log)	Visit Preview	307b557

[Siumauricio]

Reviewed and deployed the PR version of blueprints/wupnext on a Dokploy instance.

Upstream check (javierlnmn/wupnext, cloned at 6eeb579): all five new vars exist in .env.example and wupnext/settings.py:

• SITE_URL (settings.py:218, added 2026-07-27) — used for links in emails, password reset raises if unset.
• MCP_BASE_URL (settings.py:285, added 2026-08-20 in "Create base MCP server with OAuth and DCR") — feeds OAUTH2_PROTECTED_RESOURCE_IDENTIFIER / authorization servers.
• Q_WORKERS / Q_TIMEOUT / Q_RETRY (settings.py:224-226) — Django Q2 cluster config, defaults match the template (2 / 60 / 120).

Deploy (PR version):

• generate-meta.js --check, validate-docker-compose.ts, validate-template.ts all pass.
• Both containers running, RestartCount: 0; env injected as expected (SITE_URL/MCP_BASE_URL on web, SITE_URL/Q_* on worker).
• Worker log: Q Cluster ... running, 2 worker processes ready. Web log: migrations applied, superuser created, gunicorn listening on :8000.
• GET / → 302 → /accounts/login/ → 200 «WupNext» through Traefik.

One thing to fix before merging: the image the template pins (docker.io/javierlnmn/wupnext:latest) was last pushed on 2026-08-17 (same digest as 0.2.0), but the MCP server landed upstream on 2026-08-20. On the deployed instance GET /mcp, /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server all return 404, so the new description ("...and an MCP server so an AI client can work the board") and the mcp tag aren't true for the image users will actually pull today. MCP_BASE_URL is simply ignored by that build.

Could you push a new image that includes the MCP server (e.g. 0.3.0 + latest)? Ideally also pin the compose to that tag instead of :latest so the template is reproducible — I'm happy to re-test once it's up. Everything else in the PR is good.