fix(portal-clis): reject undefined single-dash flags in the unknown-flag guard (#428)

The guard in the four bunli-based CLIs inspected only tokens starting
with `--`, so an undefined short flag bypassed it: bunli discarded it,
the search ran unfiltered, and the CLI exited 0. Live against jobnet,
`search -q "sygeplejerske"` returned all 18,179 ads as a successful
search against 667 for the real `--search-string` query - the same shape
as review finding F13 that motivated the guard.

Both dash forms are now checked. Declared shorts (jobindex's -q) and
bunli's built-in -h/-v stay valid. A negative number is rejected too:
bunli discards a `-`-prefixed token rather than consuming it as the
previous flag's value, so `--radius -5` silently fell back to the
default instead of failing its own min(1) schema; a value that must
begin with a dash uses the `--flag=value` form.

Fixes #426.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

.agents/skills/jobnet-search/cli/tests/cli-flag-validation.test.ts

@@ -94,4 +94,33 @@ describe("unknown flag rejection", () => {
     expect(result.exitCode).toBe(1);
     expect(JSON.parse(result.stderr).code).toBe("UNKNOWN_FLAG");
   });
+  // #426: the guard inspected only `--long` tokens, so a single-dash flag was
+  // discarded in silence - the same failure the long-form tests above pin,
+  // reached by the likelier route. `-q` is the documented short for the
+  // keyword search in linkedin-search, freehire-search and jobindex-search,
+  // so it is what a cross-portal habit produces here; live, it returned the
+  // portal's entire database as a successful, unfiltered search.
+  test("-q (another portal's short flag) is rejected, not treated as no filter", async () => {
+    const result = await runCLI(["search", "-q", "test"]);
+    expect(result.exitCode).toBe(1);
+    expect(result.stdout).toBe("");
+    const error = JSON.parse(result.stderr);
+    expect(error.code).toBe("UNKNOWN_FLAG");
+    expect(error.error).toContain("-q");
+  });
+
+  // bunli discards a `-`-prefixed token instead of consuming it as the
+  // previous flag's value, so a negative number never reached the option's
+  // own schema - it silently fell back to the default. Loud beats silent.
+  test("a negative number is rejected instead of silently falling back to the default", async () => {
+    const result = await runCLI(["search", "--search-string", "test", "--limit", "-5"]);
+    expect(result.exitCode).toBe(1);
+    expect(JSON.parse(result.stderr).code).toBe("UNKNOWN_FLAG");
+  });
+
+  test("-h still prints help rather than being rejected as unknown", async () => {
+    const result = await runCLI(["search", "-h"]);
+    expect(result.exitCode).toBe(0);
+    expect(result.stderr).toBe("");
+  });
 });