Improve fast deployment story when app is installed manually (missing assemblies → confusing crash)

[jonathanpeppers]

Summary

When Fast Deployment is enabled (the default for Debug builds), dotnet build produces an .apk that does not contain the managed .dll assemblies — they're pushed separately to the device's override directory during the Install target via adb push/run-as.

This trips up a common manual workflow that both humans and AI agents reach for:

dotnet build
adb install path/to/my.apk

The app installs fine, launches, and then immediately crashes because no assemblies are on the device. The failure is opaque — nothing tells you that you skipped Fast Deployment and should have used dotnet build -t:Install (or disabled Fast Deployment).

Current behavior

At runtime we abort with a log_fatal. The messages today (from src/native/.../monodroid-glue.cc and the CLR host) look roughly like:

No assemblies found in '<override-dir>' ... Assuming this is part of Fast Deployment. Exiting...
FastDev assembly 'Foo.dll' not found.

Even in DEBUG this doesn't clearly tell the user what to do next, and in a logcat flood it's easy to miss. There's no in-app signal at all — just a crash.

Proposed improvements

1. In-app fallback activity — When the app detects it launched with no deployed assemblies (empty/missing override dir under Fast Deployment), show a plain Java-based Activity (no managed code required, since managed code can't run) that says something like:

   ⚠️ No .NET assemblies were deployed.
   This APK was built with Fast Deployment, which keeps assemblies out of the .apk.
   Run dotnet build -t:Install to deploy properly, or build with -p:EmbedAssembliesIntoApk=true / a Release build to produce a self-contained .apk.

2. Better logcat diagnostics — Upgrade the fatal message to be explicit and greppable, aimed at helping an AI/human self-correct, e.g.:

   FATAL: No .NET assemblies found on device. This app was built with Fast Deployment; adb install alone does not deploy assemblies. Use dotnet build -t:Install or set -p:EmbedAssembliesIntoApk=true.

Notes / open questions

• The Java activity approach is attractive because when assemblies are missing, the managed runtime can't start — so the guidance must live in Java/native.
• Should the fallback activity be Debug-only? (It should never ship in Release, where assemblies are always embedded.)
• We may be able to detect this specific condition (Fast Deployment build + empty override dir) distinctly from the "compressed assemblies in APK" failure, so the message is precise.