fix: rivet binary path resolution + drop fragile .issues guard

src/ai-review.js

@@ -382,14 +382,21 @@ async function reviewPullRequest(octokit, owner, repo, prNumber) {
     if (rivetCfg?.enabled && rivetCfg?.binary_path) {
       const headSha = prData.data.head?.sha;
       const baseSha = prData.data.base?.sha;
+      // Resolve binary path against the temper deploy root, NOT the tmpdir
+      // cwd that runRivetOracle uses. Without this, a relative binary_path
+      // like "data/rivet/rivet" gets looked up inside the freshly-extracted
+      // PR tarball — which obviously doesn't have the rivet binary in it.
+      const resolvedBinary = path.isAbsolute(rivetCfg.binary_path)
+        ? rivetCfg.binary_path
+        : path.resolve(__dirname, '..', rivetCfg.binary_path);
       try {
         if (headSha && (await hasRivetYaml(octokit, owner, repo, headSha))) {
           oracleSummary = await withTempRepoCheckout(
             octokit,
             owner,
             repo,
             headSha,
-            (repoPath) => runRivetOracle(rivetCfg.binary_path, repoPath, {
+            (repoPath) => runRivetOracle(resolvedBinary, repoPath, {
               baseRef: baseSha,
               timeout: rivetCfg.timeout_ms || 60000
             })

src/app.js

@@ -276,7 +276,13 @@ function registerApp(app, options = {}) {
     const config = getConfig();
     const { comment, repository, sender } = context.payload;
 
-    if (!comment?.body || !context.octokit?.issues) {
+    // Only check that the body is present. We previously also gated on
+    // `context.octokit?.issues` being defined, but Probot v14 doesn't
+    // *always* expose the `.issues` namespace — and silently skipping every
+    // ChatOps command when it's missing is worse than letting individual
+    // calls fail loudly (which they don't, in practice — `octokit.request()`
+    // is always available and the existing call sites use it).
+    if (!comment?.body || !context.octokit) {
       return;
     }