[TheGreatAxios]

Why

Myra never gets tools. The stock POST /workflows/deployments route passes no
toolPackagePins, so workflow_run_launch_spec.tool_package_pins is null, the
session service resolves no manifest, and the sidecar's source-deploy path
(sourceTools === true) runs only req.agent.toolFactories evaluated from the
pushed workflow.js. That entry was pure JSON with toolFactories: [] and pins
nothing ever read — an assistant with an empty tool surface.

What changed

• agents/myra/src/index.ts is now the workflow entry: it imports the real
  factories from the eight pinned tool packages (memory add/search/list,
  capability, agent-directory, catalog, skills query + manage, interaction,
  workflow-authoring, access) and builds the definition with
  toolPackagePins: []. buildMyraWorkflow takes the per-deploy values
  (trigger address, prompt, inference sources, turn timeout).
• agents/myra/scripts/build-bundle.ts bundles that entry with Bun.build
  (target bun, ESM, no externals, no minify, no sourcemaps) into
  agents/myra/bundle/workflow-bundle.js (gitignored). It fails loud if any
  non-builtin bare import survives. Wired as the package's build script and
  run from an apps/web Vite plugin's buildStart, so bun run dev,
  vite build and the root bun run build all produce it before it is needed.
• @corbits/myra/bundle exposes the bundle text via Vite ?raw;
  apps/web/src/myra-deploy.ts dynamic-imports it during setup only, so the
  ~520 KB of entry text lands in its own lazy chunk rather than the app entry.
• packages/workflows grows renderBundledWorkflowSourceTree: the entry is
  <bundle>\nexport default buildMyraWorkflow({...});. Every rendered tree
  (bundled or JSON) now also writes definition.json, the function-free
  projection, and readWorkflowSourceDefinition /
  parseWorkflowSourceDefinition read that file. parseWorkflowSourceEntry
  (the strict entry slice) is gone — a bundle cannot be sliced.
• Readers updated: apps/web/src/agent-source-read.ts and
  packages/agent-directory (AGENT_DEFINITION_ENTRY_PATH →
  AGENT_DEFINITION_JSON_PATH, parseAgentDefinitionEntry →
  parseAgentDefinitionJson).
• Myra-created agents (apps/web/src/agent-deploy.ts) keep the JSON path.
• Deleted agents/myra/src/boundary.test.ts: its premise (shipped sources
  import only @intx/*) is false by design now that the entry imports tool
  packages to be bundled. definition.test.ts is rewritten to the two facts a
  deploy depends on — factories present and namespaced, still single-step.

Verification done

• bunx tsc -p apps/web --noEmit, bun run typecheck, bun run lint,
  bun run fmt:check — clean.
• cd apps/web && bun run build — green; bundle lands in its own
  bundle-*.js chunk, entry chunk unchanged.
• bun test for agents/myra, packages/workflows, packages/agent-directory,
  apps/web/src — all green.
• Bundle evaluated under bun from a rendered entry: exports a definition with
  stepOrder: ["assistant"], toolPackagePins: [], and 11 tool factories
  (@corbits/memory/add, …/search, …/list, @corbits/capability-tools/cap,
  @corbits/agent-directory-tools/ad, @corbits/catalog-tools/catalog,
  @corbits/skills-tools/skills-query, @corbits/skills-tools/skills,
  @corbits/interaction-tools/ask-user, @corbits/workflow_authoring/wf,
  @corbits/access-tools/access).

How to verify live after merge

The running dev stack was not restarted (it serves main), so this was not
exercised against a live hub. After merge:

1. bun run dev, sign in, let the web client set the workbench up — the deploy
   pushes the bundled workflow.js.
2. Confirm the asset tree: the pushed workflow.js is ~520 KB of bundle ending
   in export default buildMyraWorkflow({...}), with definition.json beside it.
3. Ask Myra for something that needs a tool, e.g. "can you get access to GitHub
   tools?" (drives request_capability) or "what do you remember about X?"
   (drives memory_search).
4. Check the run's turn_part rows for a tool-call part — previously there
   would be none for any prompt.

[linear-code]

CL-8456

CL-8457