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

[codebuff-team]

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.

[viniciusdebruin]

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.