Improve e2e workflow caching and clean up publish workflow warnings

[fopina]

Summary

The GitHub Actions setup has two follow-up improvements worth tackling together:

1. speed up or stabilize e2e runs by caching reusable DefectDojo/Postgres state
2. resolve current warnings / shell issues in the publish workflow summary step

Problem 1: e2e workflow startup cost

The integration workflow relies on make test-e2e, which spins up DefectDojo plus Postgres via Docker Compose. When the Postgres volume is fresh, initialization work adds noticeable overhead.

Current setup details:

• support/integration/docker-compose.yml uses a named Docker volume for Postgres (defectdojo_postgres)
• GitHub-hosted runners are ephemeral, so that volume is recreated on every job
• .github/workflows/test.yml currently does not run the real command yet (echo make test-e2e), but when re-enabled it would always start from a cold DB

Proposal for e2e caching

Investigate switching the Postgres data volume to a cacheable bind mount under the workspace, then use actions/cache to persist it between runs.

Suggested acceptance criteria:

• e2e workflow runs the real make test-e2e
• Postgres data is stored in a path that can be cached by GitHub Actions
• cache key includes enough invalidation context (OS, Postgres version, DefectDojo version, bootstrap/schema version)
• workflow remains safe when cache is missing or stale
• docs/comments explain why a bind mount is used instead of a Docker named volume

Problem 2: publish workflow warnings / summary step issues

.github/workflows/publish.yml currently has a fragile summary step:

• heredocs inside the if / else branches are malformed / indentation-sensitive
• the summary block is easy to break in shell parsing
• the TestPyPI uvx guidance should be reviewed while fixing the step

Proposal for publish workflow cleanup

Refactor the summary-writing logic to avoid fragile heredocs and eliminate the warnings / shell pitfalls.

Suggested acceptance criteria:

• publish.yml writes the summary without heredoc parsing issues
• no workflow warnings from that summary step
• PyPI and TestPyPI branches both render valid install / run instructions
• TestPyPI instructions are validated so only the intended packages come from TestPyPI

Notes

This issue is intentionally scoped to workflow reliability and DX, not to changing the runtime package behavior.