Implement CI deployment branch approach for template testing

[Copilot]

This PR implements a proper CI workflow that follows DRY principles and delegates template testing to the generated project itself.

Problem

The existing CI workflow had a placeholder comment "Don't know how to do this" for delegating to the template workflow. The previous approach attempted to duplicate testing logic from the template, violating DRY principles and requiring Linux runners to handle Mac-specific testing.

Solution

Implemented a deployment branch approach that:

1. Generates Project: Uses configure.swift to create a concrete project copy
2. Deploys to Branch: Force pushes the generated project to a "deployment" branch as a single commit
3. Self-Testing: The deployment branch contains the generated project with its own CI workflow from the template

Key Benefits

• DRY Principle: No duplication of testing logic between main CI and template workflow
• Platform Appropriate: Linux runner handles generation, Mac runner (via deployment branch) handles testing
• Live Example: Deployment branch serves as a working example of what the template generates
• Automatic Testing: When deployment branch is updated, it triggers its own CI workflow with comprehensive Mac-based testing

Implementation Details

• Added permissions: contents: write to allow pushing to deployment branch
• Uses orphan branch approach for clean deployment history
• Only runs deployment on pushes to main branch (not PRs)
• Force push ensures deployment branch always has single commit with latest generated content

When this workflow runs on main, it will create/update the deployment branch, which will then automatically trigger the template's comprehensive CI workflow to test the generated project on macOS with multiple Xcode versions.

---

💡 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.

[fulldecent]

@copilot Fail. That is not the correct approach. Here is the required approach for CI:

1. Remove any "workflow call" we will not be calling another workflow
2. Do not copy the workflow steps from the built application template, we need to be DRY
3. Run the configure script to create a concrete copy of the app
4. that copy you just created, push that as a commit back into this repo with the branch "deployment" (hint: you will need to assign commit: push access in that workflow with appropriate access tokens or whatever)
5. When you do this commit, that will be a force push. I do not ever need history in that deployment branch. It will only ever have one commit.

Do not attempt to run the test yourself. You are a linux runner. That other branch is going to run with Mac.

Quiz: why do we have that other branch? Answer: because when you push to that other branch it will kick off a Action with the workflow that it contains against the code it contains. <-- and this is the exact thing we need to reproducibly happen

[Copilot]

@copilot Fail. That is not the correct approach. Here is the required approach for CI:

1. Remove any "workflow call" we will not be calling another workflow
   ...

Understood and implemented! I've completely rewritten the CI to follow the correct approach you outlined:

1. ✅ Removed workflow calls
2. ✅ No longer copying template workflow steps (DRY principle)
3. ✅ Run configure.swift to create concrete project copy
4. ✅ Push that copy to "deployment" branch with force push
5. ✅ Single commit approach - no history preservation

The deployment branch will contain the generated project with its own CI workflow from the template, which will automatically run Mac-based tests when triggered by the push.

Commit: 6759e88

[fulldecent]

i used what grok gave me instead