chore: update ChallengeType enum to match main repository

[Copilot]

This PR updates the ChallengeType enum in the mobile app to match the challenge types defined in the main freeCodeCamp repository and resolves merge conflicts that arose from integrating recent main branch changes.

Changes Made

Updated ChallengeType Enum (18-30)

Added missing challenge types that exist in the main repository:

• msTrophy (18)
• multipleChoice (19)
• python (20)
• dialogue (21)
• fillInTheBlank (22)
• multifilePythonCertProject (23)
• generic (24)
• lab (25)
• jsLab (26)
• pyLab (27)
• dailyChallengeJs (28)
• dailyChallengePy (29)
• examDownload (30)

Resolved Duplicate Value Issue

Removed frontEndProject from the enum to avoid duplicate index values, since both zipline and frontEndProject map to value 3 in the main repository. Added a comment documenting this as an alias.

Challenge Model Integration

Updated the Challenge class to use the ChallengeType enum instead of storing challengeType as an int:

• Changed Challenge.challengeType from int to ChallengeType enum
• Updated fromJson to convert API integers to enum values using ChallengeType.values[data['challengeType']]
• Updated toJson to convert enum back to integers using challengeType.index

Merge Conflict Resolution

Resolved conflicts that occurred when main branch updates introduced new challenge types (28, 29) while still using hardcoded integers. Replaced all hardcoded integer references with corresponding enum values throughout:

• challenge_view.dart: Preview button visibility logic
• challenge_viewmodel.dart: JavaScript console message handling
• template_view.dart: Challenge type routing switch cases
• test_runner.dart: Worker type and file extension mapping

Verification

All challenge types currently used in the mobile app codebase are properly covered:

• template_view.dart switch cases: ✅ 0,1,8,10,11,14,15,19,20,21,22,24,25,26,28,29
• test_runner.dart getWorkerType: ✅ 0,1,14,20,23,25,26,28,29
• Integration tests: ✅ 0,1,5,6,14,25,26

The enum indices now correctly match the main repository's challenge type values, enabling future migration to use enum values directly instead of hardcoded integers while maintaining full backward compatibility.

Fixes #1534.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[huyenltnguyen]

Could you also address this comment: #1534 (comment)?

You will need to update the Challenge class in challenge_model to use the ChallengeType enum.

[Copilot]

Could you also address this comment: #1534 (comment)?

You will need to update the Challenge class in challenge_model to use the `Chall...

I've updated the Challenge class to use the ChallengeType enum instead of storing challengeType as an int. The changes include:

• Changed Challenge.challengeType from int to ChallengeType enum
• Updated fromJson to convert API integers to enum values using ChallengeType.values[data['challengeType']]
• Updated toJson to convert enum back to integers using challengeType.index
• Added backward compatibility getter challengeTypeIndex for existing code that expects integers
• Updated all references throughout the codebase to use the new structure

This implements the suggestion from the linked comment to start using the enum when storing challenge type in the challenge object. Commit: 00977e2

[huyenltnguyen]

Approving the changes Copilot made, but I added some changes too, so this PR needs another set of eyes.

[huyenltnguyen]

I'm keeping frontEndProject instead of zipline because zipline is an older term and I think we've stopped using it.

[huyenltnguyen]

@copilot address the merge conflicts. Ensure that the implementation logic remains unchanged, and only substitute the numbers with the corresponding enum values.

[Copilot]

@copilot address the merge conflicts. Ensure that the implementation logic remains unchanged, and only substitute the numbers with the corresponding enum values.

I've resolved all merge conflicts by replacing hardcoded integers with their corresponding ChallengeType enum values. The implementation logic remains unchanged - I only substituted:

• 1, 26, 28 → ChallengeType.js, ChallengeType.jsLab, ChallengeType.dailyChallengeJs
• 20, 23, 27, 29 → ChallengeType.python, ChallengeType.multifilePythonCertProject, ChallengeType.pyLab, ChallengeType.dailyChallengePy
• And similar mappings for other challenge types

All affected files (challenge_view.dart, challenge_viewmodel.dart, template_view.dart, test_runner.dart) now use the enum consistently while preserving the exact same functionality. Commit: bb5b534

[huyenltnguyen]

Holding this PR as there is a change to a challenge type: freeCodeCamp/freeCodeCamp#61963.

We'll also need to address failed tests.