refactor: use cached template for fallback challenge pages instead of hardcoded HTML

Previously, fallbackJSChallenge and fallbackCaptchaChallenge used large hardcoded
HTML strings with fmt.Sprintf(), causing:
1. Code duplication (same HTML in multiple places)
2. Sprintf overhead on every fallback call
3. Increased binary size
4. Maintenance burden (changes needed in multiple places)

Solution:
- fallbackJSChallenge now uses the cached cm.template with ChallengeTemplateData
- fallbackCaptchaChallenge now uses the cached cm.template
- Extracted generateSimplePoWScript() for the JavaScript logic
- Both functions now reuse the same template system as primary challenges
- Ultimate fallback returns HTTP 503 if even template fails (unlikely)

Benefits:
- No code duplication (single source of truth for HTML/CSS)
- Better performance (no Sprintf on every call)
- Smaller binary (removed ~400 lines of hardcoded HTML)
- Consistent design (all challenges use same template)
- Easier maintenance (template changes apply everywhere)

Testing:
- All tests pass: go test ./...
- Build successful: go build ./...
- Code formatted: go fmt ./...

Author: Rxflex