Add E2E tests for task submission workflow

[success-OG]

Summary

This PR implements end-to-end test coverage for the complete task submission workflow, from task creation through successful work submission and status verification. It adds the missing API layer needed to exercise that flow in tests and wires those tests into frontend CI so they run on every pull request.

Previously, the frontend only supported file validation via POST /api/task-submissions/validate. There was no way to create a task, submit work against it, or verify that task status changed after submission. This PR closes that gap with a lightweight in-memory task workflow and API routes that mirror the TaskBounty contract behavior closely enough for reliable E2E testing.

What changed

Task workflow service

• Added frontend/src/lib/task-workflow.ts with in-memory task and submission storage
• Supports:
  • Create task — validates poster, title, description, reward, deadline, and max submissions
  • Submit work — validates contributor, description, and uploaded files
  • Status transitions — moves task from open → in_progress on first successful submission
• Added resetTaskWorkflowStore() for deterministic test isolation between cases
• Added shared types in frontend/src/types/task-workflow.ts

New API routes

Method	Route	Description
POST	/api/tasks	Create a new task with status open
GET	/api/tasks/[taskId]	Fetch task details and current status
POST	/api/tasks/[taskId]/submissions	Submit work with multipart file upload and metadata

Submission requests reuse the existing file validation logic from task-submission-files.ts, so uploads still go through the same security checks (extension allow-list, MIME/content matching, size limits, filename safety).

End-to-end tests

Added frontend/src/lib/task-submission-e2e.test.ts with full workflow coverage:

1. Happy path

   • Create a task
   • Confirm initial status is open
   • Submit valid work with a PDF proof file
   • Confirm submission is created with pending status
   • Confirm task status updates to in_progress
   • Confirm submission count increments to 1

2. Duplicate submission protection

   • Reject a second submission from the same contributor with 409
   • Ensure task state does not change incorrectly

3. Invalid task creation

   • Reject missing title, low reward, and past deadline with 400
   • Return structured validation details

4. Invalid file submission

   • Reject submissions with no files
   • Ensure task remains open and submission count stays 0

CI integration

Updated .github/workflows/frontend-ci.yml to run pnpm test before pnpm build, so the new E2E tests are enforced in GitHub CI and not just locally.

Build fix

Fixed duplicate JSX attributes in frontend/src/components/Navbar.tsx that were causing the TypeScript production build to fail.

Acceptance criteria

• Create a task
• Submit task successfully
• Verify task status updates
• Tests run in CI

Design notes

This implementation uses an in-memory store rather than on-chain contract calls because the active frontend does not yet have Soroban client wiring for task lifecycle operations. The workflow intentionally mirrors the reference TaskBounty contract semantics:

• Tasks start as open
• First valid submission moves them to in_progress
• Duplicate contributor submissions are blocked
• Expired or invalid tasks reject submissions

That makes these tests a useful regression suite now and a stable foundation once the UI and contract integration are added later.

Test plan

• cd frontend && pnpm test
  • 27 tests pass across 4 files
  • Includes 4 new E2E workflow test cases
• cd frontend && pnpm build
  • Production build succeeds
  • New API routes appear in build output:
    • /api/tasks
    • /api/tasks/[taskId]
    • /api/tasks/[taskId]/submissions
• Verify GitHub Frontend CI passes on this PR
• Manually smoke-test API routes locally if desired:
  • Create task via POST /api/tasks
  • Fetch task via GET /api/tasks/{id}
  • Submit work via POST /api/tasks/{id}/submissions

Follow-ups (out of scope)

• Persist tasks to a database or on-chain contract
• Add UI pages for task creation and submission
• Add Playwright/browser-based E2E tests once the submission UI exists

closes #85