Fix duplicate Program class by removing WPF-specific property from WinUI project

[Copilot]

Build failed with duplicate Program class definitions after adding custom entry point with error handling.

Root Cause

EnableDefaultApplicationDefinition=false in the project file is a WPF/WinForms property. WinUI 3 ignores it but may still trigger Program class generation, conflicting with the custom Program.cs.

Changes

LlamaRun.csproj

• Removed <EnableDefaultApplicationDefinition>false</EnableDefaultApplicationDefinition>

WinUI 3 automatically detects custom Program.cs files based on signature presence - no property configuration needed.

Technical Context

<!-- Before: Incorrect for WinUI 3 -->
<PropertyGroup>
  <UseWinUI>true</UseWinUI>
  <EnableDefaultApplicationDefinition>false</EnableDefaultApplicationDefinition>
</PropertyGroup>

<!-- After: Let WinUI auto-detect custom Program.cs -->
<PropertyGroup>
  <UseWinUI>true</UseWinUI>
</PropertyGroup>

The custom Program.cs with crash logging and error handling remains unchanged and is now correctly used as the sole entry point.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Refactor Llama Run Core Project: Split into Unpackaged and Packaged Projects</issue_title>
<issue_description>## Summary

The Llama Run Core Project is currently structured as a packaged app. This makes it dependent on MSIX tooling and unable to run without packaging. To enhance flexibility and developer experience, we need to refactor the core into two separate projects:

• Unpackaged Core Project (e.g., LlamaRun): A standalone application built as a .exe, usable for development, debugging, and testing outside MSIX tooling.
• Packaged App Project (e.g., LlamaRun.Packaged): Built on top of the unpackaged app using Visual Studio's packaged app template.

Motivation

• Enable running and testing the core without dependencies on MSIX or packaging tools.
• Improve CI/CD integration by supporting builds in environments where MSIX packaging is unnecessary.
• Leverage Visual Studio's tooling to streamline the transition from unpackaged to packaged apps for production deployment.
• Maintain feature parity while supporting the potential for additional use cases.

Suggested Approach

• Refactor LlamaRun as a standalone, unpackaged app executable.
• Create LlamaRun.Packaged project with Visual Studio's packaged app template configured as a wrapper around the unpackaged app.
• Ensure distinction between development workflows (unpackaged) and production workflows (packaged).
• Update documentation to delineate the configuration, build, and launch processes for both projects.

Tasks

• Establish LlamaRun as the core unpackaged app project (outputs .exe).
• Utilize Visual Studio's packaged app template to create LlamaRun.Packaged, referencing the unpackaged app.
• Adapt all build tasks to ensure they handle both packaged and unpackaged configurations.
• Ensure separate but streamlined launch configurations for development and production modes.
• Write CI/CD pipelines to validate functionality and builds for both project types.
• Update documentation to accurately reflect the splitting and usage of projects.

Acceptance Criteria

• Unpackaged app is functional, serving as the base logic and executable for LlamaRun.
• Packaged app wraps the unpackaged app and is functional with MSIX tooling.
• All build tasks and pipelines function seamlessly between the two configurations.
• Documentation and workflows are updated to reflect the changes without loss of clarity or functionality for contributors.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Refactor Llama Run Core Project: Split into Unpackaged and Packaged Projects #10

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.