Build system improvements

[dh0er]

No description provided.

[rcawston]

Hi @dh0er, thank you for the pull request!

I’d like the following changes before merging:

1. Apply pass-through args when locating the built app

   build.sh documents that arguments after -- are passed through to xcodebuild, and the build command does pass "$@". However, the later -showBuildSettings calls do not pass "$@", so they may compute BUILT_PRODUCTS_DIR / FULL_PRODUCT_NAME for a different build configuration than the one actually used.

   This can break copying when callers pass flags such as -derivedDataPath, SYMROOT=..., CONFIGURATION_BUILD_DIR=..., -sdk, -destination, or signing overrides.

2. Guard against empty product-path values before copying

   The script currently builds:

   APP_SRC="$BUILT_PRODUCTS_DIR/$FULL_PRODUCT_NAME"

   and then only checks:

   [[ ! -d "$APP_SRC" ]]

   If either parsed setting is empty, the script can target the wrong path. Please add explicit non-empty checks for BUILT_PRODUCTS_DIR and FULL_PRODUCT_NAME before constructing APP_SRC. It would also be reasonable to verify that FULL_PRODUCT_NAME ends in .app.

3. Update CI to exercise the new build.sh

   The existing workflow still invokes xcodebuild build directly, with signing overrides, instead of using the new script. That means the green Debug/Release checks do not validate the new artifact-copying path added by this PR.

4. Remove the now-redundant Preview Content workaround in CI

   Since the PR adds Overlook/Preview Content/.gitkeep, the workflow step that manually creates Overlook/Preview Content should no longer be necessary.

5. Remove the .vscode files from this PR

   I think the .vscode files should be removed from this PR. They are editor-specific convenience configuration rather than required build-system state, and this project already has the canonical Xcode project/scheme plus build.sh for command-line builds.

   Committing these would effectively bless VS Code + CodeLLDB as a repository-level workflow and may prompt contributors to install an extension they do not need. If VS Code support is desired, I’d prefer documenting the setup in README.md or adding an opt-in sample under something like docs/vscode/, rather than committing .vscode/ directly.

   Adding .vscode/ to .gitignore would be my preference.

Thanks again for the PR — once these are addressed, I’m happy to take another look.