fix: make root Bun installs accessible to systemd

[omglazrgunpewpew]

Description

Root Linux installs could create /usr/local/bin/bun as a symlink to /root/.bun/bin/bun while the systemd service runs as the unprivileged hivekeep user. When /root is mode 0700, systemd cannot traverse that path and the service fails with 203/EXEC.

This change gives root Linux installs a fixed managed Bun location at /usr/local/lib/hivekeep/bun, verifies the selected executable as the service user, and copies an inaccessible Bun into that managed location without changing the legacy /usr/local/bin/bun link. The generated unit uses the verified absolute executable, receives the matching Bun directory in PATH, and resets a failed unit before starting so a repaired install is not blocked by systemd's start limit.

The installer also persists the verified root runtime in root-owned metadata, uses that metadata for root diagnostics, and runs Bun probes as hivekeep with a minimal environment. Non-root installs keep their normal user-local Bun behavior.

For existing v1.9 installs affected by #34, rerun the updated installer after this change is available. An updater process that started from the old installer cannot repair itself during that same run because it continues executing the old script.

Type of Change

• Bug fix
• New feature
• Refactor / cleanup
• Documentation
• CI / Build
• Tests
• Breaking change
• Other

Related Issues

Fixes #34

How to Test

• Unit tests (bun test)
• Manual testing
• N/A (docs only)

Validation completed:

• sudo bash tests/install-bun-path.sh: all 14 installer regression cases passed
• bash -n install.sh tests/install-bun-path.sh docker/entrypoint.sh
• shellcheck -S error install.sh tests/install-bun-path.sh
• bun run typecheck
• Repository pre-commit suite: 3,985 passed, 109 skipped, 0 failed
• bun run build
• Live Ubuntu systemd smoke test: active and running, nonzero main PID, zero execution status, and Bun 1.3.14 executed as the service user
• Live start-limit reproduction confirmed that daemon-reload alone does not clear Start request repeated too quickly; the service creation path now resets the failed state before starting, with command-order regression coverage

Checklist

• I've read the Contributing Guide
• I've tested this locally
• The build passes (bun run build)
• TypeScript compiles without errors (tsc --noEmit)
• New code follows existing patterns and conventions
• I've added tests for new functionality (if applicable)
• I've updated documentation if needed
• User-facing strings use useTranslation() with keys in both en.json and fr.json
• No hardcoded colors - uses semantic CSS variables or Tailwind tokens
• Shared types in src/shared/types.ts, shared constants in src/shared/constants.ts
• Breaking changes are noted above (if any)