chore: [SDK-4711] clean up .NET demo build warnings

[fadi-george]

Description

One Line Summary

Clean up build warnings surfaced by the .NET demo builds without changing existing runtime contracts.

Details

Motivation

SDK-4711 tracks build warning cleanup for the .NET SDK demos. The goal is to keep demo builds warning-free across iOS and Android while preserving existing SDK behavior for nullable values and optional native modules.

Scope

This PR enables nullable annotations where they reflect existing behavior, fixes warning-producing authored code, and suppresses generated binding diagnostics in binding projects only. It also keeps existing null-return behavior for user IDs, push IDs/tokens, tag reads, and iOS native conversion helpers.

Other

Android binding warning cleanup removes legacy explicit framework references and scopes NoWarn to binding projects. iOS generated binding warnings are suppressed in the binding project only.

Testing

Unit testing

No unit tests were added; these changes are focused on build warnings, nullable annotations, generated binding diagnostics, and demo project build configuration.

Manual testing

Validated the demo builds locally:

• dotnet build examples/demo/demo.csproj -f net10.0-ios --no-restore
• dotnet build examples/demo/demo.csproj -f net10.0-android --no-restore
• dotnet build examples/demo-no-location/demo-no-location.csproj -f net10.0-android --no-restore

All completed with 0 warnings and 0 errors.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

Made with Cursor

[fadi-george]

@claude review once

[fadi-george]

@claude review once