Problem

In split-portfolio v2 mode, the adopter's private sibling repo contains a fully-configured onboarding.yaml (company info, Jira tracker, team structure, tech stack). The framework's _lib-portfolio-paths.sh helper correctly resolves the registry, projects dir, workspace, and agent routing from the sibling repo — but not onboarding.yaml.

At session start, the CLAUDE.md instruction says:

Read onboarding.yaml for company-specific configuration

There is no qualification about which repo to read from. Claude Code resolves this relative to CWD, which in a split-portfolio session is the public fork root — not the sibling. The sibling's properly-configured onboarding.yaml is silently ignored; the fork's copy (still at template defaults after /split-portfolio runs) is read instead.

The result: every session starts with template placeholder values ("Your Company Name", tool: "GitHub Issues", ticket_prefix: "GH") even when the adopter has a fully-configured sibling copy.

Steps to reproduce

1. Run /split-portfolio on a single-fork adopter
2. Fill in onboarding.yaml in the resulting sibling (private) repo
3. Open a new Claude Code session from the public fork root
4. Ask Claude to describe the company or the project management tool
5. Observe: Claude reports template defaults, not the sibling's values

Expected behaviour

_lib-portfolio-paths.sh should expose a portfolio_onboarding_yaml resolver (same pattern as portfolio_registry, portfolio_projects_dir, portfolio_workspace_dir, portfolio_agent_routing) that:

• In single-fork mode: returns <ops_root>/onboarding.yaml (current behaviour, unchanged)
• In split-portfolio mode: returns <private_sibling>/onboarding.yaml

The CLAUDE.md session-start instruction should be updated to resolve via the helper:

source "$(git rev-parse --show-toplevel)/.claude/hooks/_lib-portfolio-paths.sh"
onboarding=$(portfolio_onboarding_yaml)
# Read $onboarding

Why this matters

onboarding.yaml carries the tracker tool (Jira vs GitHub Issues), ticket_prefix, team structure, and company context. Without it, every role activation, ticket creation, and PR workflow instruction operates on wrong defaults. It is arguably the most important adopter-configuration file — it should be one of the first paths the helper resolves, not a gap.

Acceptance criteria

• portfolio_onboarding_yaml function added to _lib-portfolio-paths.sh
• Resolves to sibling path in split-portfolio mode, fork path in single-fork mode
• CLAUDE.md session-start instruction updated to use the resolver
• Unit test added to _lib-portfolio-paths.sh test suite
• /split-portfolio output mentions that onboarding.yaml should be filled in the sibling, not the fork