C4 follow-up #1: split canFileCeoStrategy from canRequestHire for file_approval tool scope

Old internal-tool-selector attached `file_approval` to any agent with
`reportsTo === null`, and attached both tools through the same
management-keyword predicate chain. That let a VP or director with
org-management authority walk away with `file_approval`, contradicting
the C4 commit narrative that scoped `approve_ceo_strategy` as CEO-only.

Introduce `canFileCeoStrategy(db, companyId, agentId)` as a dedicated
predicate requiring both a CEO-equivalent role/title AND
`reportsTo === null`. Using either half alone is too loose: role alone
lets a demoted CEO with a virtual superior still file strategy,
`reportsTo` alone lets a VP with no manager slip through. The two
conditions together pin the predicate to a genuine top-level CEO.

- `hire_agent` continues to gate on `canRequestHire` (managers hiring
  ICs is a legitimate flow and the original "CEO-only" framing in the
  C4 commit message was narrower than the production reality).
- `file_approval` now gates on `canFileCeoStrategy`, orthogonal to hire
  authority.
- New unit test covers 4 edges: genuine CEO, CEO title with virtual
  superior, VP without manager, and plain IC.

src/main/orchestration/internal-tool-selector.ts

@@ -6,12 +6,20 @@
  * re-derives this. Rule set, in order:
  *
  *  - An agent that `canRequestHire` (CEO, HR, dept lead with reports,
- *    anyone with org-management authority) receives `hire_agent`.
- *  - A CEO (reportsTo null) additionally receives `file_approval` so
- *    the `approve_ceo_strategy` flow works without the HTTP shim. Peer
+ *    anyone with org-management authority) receives `hire_agent`. A
+ *    manager hiring an IC is a legitimate flow.
+ *  - An agent that `canFileCeoStrategy` (genuine CEO: CEO-equivalent
+ *    role + `reportsTo === null`) receives `file_approval` so the
+ *    `approve_ceo_strategy` flow works without the HTTP shim. Peer
  *    agents use the HTTP path until the file_approval surface is
  *    generalised.
  *
+ * The two predicates are intentionally orthogonal — a VP with hiring
+ * authority should not inherit CEO-strategy approval scope, and a CEO
+ * with a virtual superior inserted above them should not silently
+ * lose strategy scope either (guarded by `canFileCeoStrategy`'s role
+ * check, not just `reportsTo`).
+ *
  * No hedging, no sentinel values: if the DB lookup throws the caller
  * is already in a broken state and should not silently fall through
  * to an empty tool set.
@@ -19,7 +27,7 @@
 
 import type { AppDatabase } from "@main/database";
 import type { AgentRecord } from "@shared/types";
-import { canRequestHire } from "@main/agent-permissions";
+import { canFileCeoStrategy, canRequestHire } from "@main/agent-permissions";
 
 export type InternalToolName = "hire_agent" | "file_approval";
 
@@ -31,11 +39,7 @@ export function resolveInternalToolsForAgent(
   if (canRequestHire(db, agent.companyId, agent.id)) {
     tools.push("hire_agent");
   }
-  // `file_approval` is currently scoped to the CEO (no manager) because
-  // the canonical use case (`approve_ceo_strategy`) is CEO-only and
-  // the broader approval surface ships via the HTTP route for now.
-  // Widen the predicate when non-CEO agents need tool-call approvals.
-  if (agent.reportsTo === null) {
+  if (canFileCeoStrategy(db, agent.companyId, agent.id)) {
     tools.push("file_approval");
   }
   return tools;