Fix Completion Logic for Unavailable Content

[edschema]

Description
Content that is not supported in the mobile app does not load, but if a user scrolls to the bottom and clicks "next" the content will be marked as complete.

Desired Behavior
Do not allow content to be marked as complete if it is not able to be loaded

Additional improvements:

• Add some indicator that certain content is not supported in mobile from the outline
• For unsupported blocks that are completed on web, allow some visibility for student for assessment types.

[edschema]

Initial analysis
Web completion callbacks are not attributed to the block that produced them. AjaxProvider posts a global NSNotification.blockCompletion with no originating block id, and CourseUnitView handles that notification by reading viewModel.selectedLesson().id at notification time before submitting /api/completion/v1/completion-batch. If a web-backed block emits completion when the learner scrolls to the bottom and the learner taps Next before the async notification is applied, iOS can submit completion for the newly selected block, including an unsupported block.

Proposed fix shape (for review)

1. On iOS, carry the originating block id through the web completion callback. Do not translate NSNotification.blockCompletion into viewModel.selectedLesson().id.
2. On iOS, update local completion state for the submitted block id, not for whatever lesson is selected when the network task returns.
3. Keep Android's web-backed rendering policy separate from the iOS attribution fix. Do not make studentViewMultiDevice a blanket Android completion whitelist without a product decision.
4. On Android, verify the affected block's actual path: HtmlUnitFragment, NotAvailableUnitFragment, or another native renderer. If it reaches HtmlUnitFragment, completion may be legitimate if the content loaded and emitted its own completion event. If it reaches NotAvailableUnitFragment, the app should not mark it complete through navigation or stale state.
5. Keep unsupported-content display behavior separate from completion eligibility, so unsupported messages never imply completion eligibility.
6. Decide separately whether backend completion-batch should reject or ignore mobile-client submissions for mobile-unsupported blocks. This is a larger product/architecture decision because the endpoint currently has no client-context/mobile-support contract.
7. Add regression tests for the iOS delayed-callback/selection-change path and an Android test proving unsupported fallback navigation does not mutate completion.