Add cross-platform source installers

[viniciusdebruin]

Summary

• add a Linux/macOS installer at install/install-unix.sh
• add a Windows installer at install/install-windows.bat
• clone or update a selected repository branch, install dependencies, build the Freebuff binary, and place it in a user-local bin directory
• document installing the official branch or a fork/custom branch in README.md

The repository and branch are configurable through FREEBUFF_REPO_URL and FREEBUFF_BRANCH, so the scripts do not depend on a personal fork by default.

Validation

• bash -n install/install-unix.sh
• git diff --check
• Windows batch syntax reviewed; Windows execution was not available in this environment

Thanks for taking on cross-platform installers — this is generally the kind of contribution that's useful, and the unix script (set -euo pipefail, idempotent clone/fetch, PATH check) is written carefully.

But the whole thing hinges on assumptions I can't confirm are correct for this repo:

• Both scripts assume a bun run build:freebuff script exists and produces exactly cli/bin/freebuff (or freebuff.exe) plus cli/bin/tree-sitter.wasm. If the actual build output path, script name, or artifact set differs even slightly, this fails silently for every user who runs it — and there's no way for me to verify this against the current build tooling from the diff alone.
• The example in README (FREEBUFF_BRANCH=contrib/engine-recovery, mentioning a "recovery-retry version") references a branch/feature that has no connection to this PR or repo history that I can see. That's a strange, oddly specific example to put in permanent docs — worth replacing with something generic like my-feature-branch.
• No mechanism to validate the scripts actually run to completion (the PR body admits Windows execution wasn't tested, and the unix test was just bash -n, a syntax check, not a real run).
• 220 lines of install scripting for something the project may already provide differently (there's a quick-start above line 28 in README that this doesn't reconcile with) risks becoming a second, divergent "official" install path that goes stale.

Before this can be ported, please confirm against the actual build scripts (package.json build:freebuff, output directory) and drop the confusing branch example. A short CI job that actually runs the install script end-to-end would go a long way here too.

Thanks for the detailed review. Here is the context and the validation I can provide:

• The implementation in this PR was produced by OpenAI Codex at my request. I am developing on an older MacBook Pro running Linux Mint, where Freebuff was not working initially. The Sol model helped identify a working approach, and I asked it to prepare this pull request to help the community.
• I verified the repository build contract locally: package.json defines build:freebuff as bun freebuff/cli/build.ts 0.0.0-dev, which invokes the Freebuff binary build. On Windows, it produced cli/bin/freebuff.exe and cli/bin/tree-sitter.wasm, and the installer copied both artifacts into the user-local Freebuff bin directory.
• I agree that the README branch example should be generic, such as my-feature-branch, rather than referencing contrib/engine-recovery.
• I also agree that an end-to-end CI check is preferable to bash -n alone. It should run the installer in an isolated temporary checkout, verify both artifacts, and invoke --version and --help before declaring success.
• The quick-start instructions should be reconciled so the installer is the single documented path instead of maintaining a second divergent setup flow.

I am happy to update the PR with those documentation and CI adjustments if the maintainers would prefer them in this contribution.

Apologies — this PR was auto-closed by GitHub when we force-pushed a history rewrite of this repository (repository maintenance; every commit SHA changed). That was not a judgment on this PR, and GitHub does not allow us to reopen it because the commits it was based on no longer exist in the new history.

If you'd like to continue with this change: rebase your branch onto the new main (or recreate it from a fresh clone) and open a new PR — feel free to link back to this one for context, and we'll pick up the review there.

Sorry for the churn, and thanks for contributing.