Closes #198.

I just assumed this was on by default 😭

In fact, the documentation says it is, but it's very clearly not!
```
/**
 `NSSavePanel`/`NSOpenPanel`: Set to `YES` to show the "New Folder" button. Default is `YES`.
 */
open var canCreateDirectories: Bool
```

Also configures the linter to pick up on unused arguments, and configures the formatter to not format them out (by setting them to _). If this was the case prior, this bug wouldn't have happened.

I undid the work of #114 in #158, by disabling the VPN toggle when the network extension was unconfigured.
When signed out, the network extension is unconfigured.
This PR adds a special exception to make the VPN toggle always clickable when signed out, as it has special behaviour when signed out.
It also adds a proper regression test. A slightly different regression test existed, but it didn't account for cases where the VPN state is one that would normally disable the toggle.

#207)

Prevents scenarios like the following, where newlines are pasted in by accident:

<img width="555" height="246" alt="image" src="/api/flow.js?q=https%3A%2F%2Fgithub.com%2Fcoder%2Fcoder-desktop-macos%2Fcompare%2F%253Ca%2520href%3D"https://github.com/user-attachments/assets/5f473dd4-dc11-4a28-a3b2-9e7bc57d033f">https://github.com/user-attachments/assets/5f473dd4-dc11-4a28-a3b2-9e7bc57d033f" />

The Windows app has trimming in the same places.

Closes #188.

If the workspaces view exceeds 400px in height, it'll become scrollable. The diff without whitespace changes is like 4 lines.

https://github.com/user-attachments/assets/5bdd0369-c882-4085-9513-7594bd100475


I think the `View more`/`View less` very much still makes sense, so I'm keeping it.

Supposedly users are missing the notification because it's just silently appearing in the background.

Some flakey OS operation has been reported by two different users after installation:
<img width="215" height="415" alt="image" src="/api/flow.js?q=https%3A%2F%2Fgithub.com%2Fcoder%2Fcoder-desktop-macos%2Fcompare%2F%253Ca%2520href%3D"https://github.com/user-attachments/assets/e632071d-02a3-45d3-bbef-f1bce9139974">https://github.com/user-attachments/assets/e632071d-02a3-45d3-bbef-f1bce9139974" />
<img width="247" height="191" alt="image" src="/api/flow.js?q=https%3A%2F%2Fgithub.com%2Fcoder%2Fcoder-desktop-macos%2Fcompare%2F%253Ca%2520href%3D"https://github.com/user-attachments/assets/dcd4b39b-5be4-4630-a4c8-dc45fe06bb77">https://github.com/user-attachments/assets/dcd4b39b-5be4-4630-a4c8-dc45fe06bb77" />

I don't know what's happening because the error handling here isn't very good. This PR fixes that by always including the operation that failed in the UI message.

First step in addressing #201.

This PR installs and kickstarts the LaunchDaemon as part of the `.pkg` installer, instead of requiring it be approved via the UI. As such, we no longer distribute the app contained within a `.zip`.

This PR adds a build script to install the LaunchDaemon when developing locally, to ensure it stays up to date when changes are made. Installing the LaunchDaemon requires administrator privileges, so to minimise password prompts, we only restart it when the binary itself, or any of it's frameworks have changed.

There's an Apple Developer Forum thread where I replied, enquiring about this installer approach vs the existing SMAppService approach, esp. w.r.t deploying the app via MDM: https://developer.apple.com/forums/thread/766351?answerId=850675022&page=1#851913022


(This PR previously had UI changes, and I did some refactoring. That refactoring is still in the diff.)

Continues to address #201.

This PR reworks all XPC connections, such that the networking code runs within the privileged helper, instead of the network extension.

The XPC interfaces are described in `XPC.swift`, and roughly follow this sequence diagram: 
(One difference is that we don't posix spawn the tunnel in this PR)
```mermaid
sequenceDiagram
    note left of App: User requests to start VPN:
    App->>+NetExt: Start VPN
    NetExt->>+PrivHelper: Request start VPN with TUN FD
    note right of PrivHelper: Privileged helper downloads and verifies binary.
    PrivHelper->>Tunnel: posix_spawn child process with FDs
    PrivHelper->>+Tunnel: Send proto start request
    Tunnel-->>-PrivHelper: Send proto start response
    PrivHelper->>+NetExt: Request for network config change
    NetExt-->>-PrivHelper: Response for network config change
    PrivHelper-->>-NetExt: Start VPN respons
    NetExt-->>-App: VPN started
    App->>PrivHelper: Request peer state
    PrivHelper->>Tunnel: Request peer state
    Tunnel-->>PrivHelper: Peer state response
    PrivHelper-->>App: Peer state response

    note left of App: Tunnel updates (bypass NetExt):
    Tunnel->>PrivHelper: Tunnel update proto message
    PrivHelper->>App: Tunnel update proto message

    note left of App: User requests to stop VPN:
    App->>+NetExt: Stop VPN
    NetExt->>+PrivHelper: Request stop VPN
    PrivHelper->>+Tunnel: Request stop VPN
    Tunnel-->>-PrivHelper: Stop VPN response
    note right of Tunnel: Tunnel binary exits
    PrivHelper-->>-NetExt: Stop VPN response
    NetExt-->>-App: VPN stopped

```

Of note is that the network extension starts and stops the daemon running within the privileged helper.
This is to support starting and stopping the VPN from the toggle in System Settings, and to ensure the "Connecting" and "Disconnecting" phase of the system VPN is indicative of the time the VPN is actually setting itself up and tearing itself down.

To accomplish this, the privileged helper listens on two different service names. One is connected to by the app, the other the network extension. (Once an XPC listener is connected to, communication is bidirectional)

Continues to address #201.

I've manually tested that this change prevents binaries not signed by the Coder Apple development team from connecting to the Helper over XPC.

Most of the PR diff is me moving the validator out of `Download.swift` and into `Validate.swift`

Closes #201.

This PR:
- Replaces the dylib download with a slim binary download.
- Removes signature validation checks that are inappropriate for the slim binary.
- Replaces `TunnelHandle` with `TunnelDaemon`, an abstraction which runs `posix_spawn` on the slim binary, and manages the spawned process.
- Adds tests for `TunnelDaemon`.


In a future PR:
- Bump the minimum server version for Coder Desktop for macOS (to v2.25 once it's released)

Relates to #201.

**After we've validated the binary signature**, we exec `coder version --output=json` to validate the version of the downloaded binary matches the server. This is done to prevent against downgrade attacks, and to match the checking we had on the dylib before.


Additionally, this PR also ensures the certificate used to sign the binary is part of an Apple-issued certificate chain.

I assumed we were checking this before (by default) but we weren't. 
Though we weren't previously checking it, we were only ever downloading and executing a dylib. 
My understanding is that macOS won't execute a dylib unless the executing process and the dylib were signed by the same Apple developer team (at [least in a sandboxed process](https://developer.apple.com/forums/thread/683914), as is the Network Extension).

Only now, when `posix_spawn`ing the slim binary from an unsandboxed LaunchDaemon, is this check absolutely necessary.

With the changes made in #203, it now takes a moment longer to receive the first progress update, when we either start the download (if not already downloaded), or validate the dylib. To address this, the progress indicator will immediately start making progress towards 25%. This prevents it from appearing stuck in what is an expected situation.


https://github.com/user-attachments/assets/da57270d-a50b-49ab-9e53-ae02368c71dc

This PR prevents issues like:

<img width="428" height="171" alt="Screenshot 2025-07-30 at 3 57 07 pm" src="/api/flow.js?q=https%3A%2F%2Fgithub.com%2Fcoder%2Fcoder-desktop-macos%2Fcompare%2F%253Ca%2520href%3D"https://github.com/user-attachments/assets/729055b8-bc9b-43fc-9e95-ed9faa384872">https://github.com/user-attachments/assets/729055b8-bc9b-43fc-9e95-ed9faa384872" />

which occur when the app is launched as root. This can happen when the installer scripts are run as root, which is the case when deploying Coder Desktop over MDM. (As a convenience, we re-open the app if it was open before the installer was ran.)

Of note is that on macOS, it is not sufficient to just run open with `sudo -u`, as that does not use the execution context of the user. See https://developer.apple.com/forums/thread/78332


Reports of the bug in other programs:
(with an incorrect solution) https://community.zoom.com/t5/Zoom-Meetings/A-keychain-cannot-be-found-to-stoer-quot-Zoom-quot/m-p/51059 
https://displaylink.org/forum/showthread.php?p=97176

This requirement is introduced by #210, as the `vpn-daemon` command on the macOS CLI isn't present on prior versions.

(2.24.3 isn't out yet, but when it does come out, it'll be compatible. 2.25 is out, and it's compatible)

Currently, in the Login Form, we reject non-https URLs. When this HTTPS requirement was added, the Coder Desktop app was unable to make HTTP requests, as it did not have `NSArbitraryLoads`. We ended up needing to enable that flag in order to use the Agent API. (`http://workspace.coder:4`)

To support Coder deployments behind VPNs without HTTPS, we can now loosen the requirement. With this PR, the behavior [matches Windows.](https://github.com/coder/coder-desktop-windows/blob/ac22fe4c44dea03b21557b4a0f1e214397bc3ea4/App/Services/CredentialManager.cs#L175-L176)

I added this block of code as a convenience, during the time we were using a workaround for the XPC issue that involved deleting and reinserting the network extension when updated. This block of code meant the user didn't need to click back into the tray menu to get the VPN configuration prompt to appear, it would just appear as soon as necessary.

However, this introduces a race. If the app loads the VPN unconfigured view before the task that checks for an existing VPN configuration finishes (this task runs as part of `applicationDidFinishLaunching`), the user will be displayed the prompt to reconfigure, even if a valid configuration already exists.

Since we're not using the aforementioned workaround, this convenience is no longer necessary, and can be removed as the race is more likely to be an issue.