fix: preserve active profile and project in preflight

[GautamSharma99]

Summary

Fixes #137.

The readable Codex preflight projection now guarantees that a valid selected profile and the valid active repository trust entry are considered before the 256-entry collection limits are filled.

Previously, profiles and projects were truncated by raw object insertion order. Entries after position 256 were never validated, even when they were the selected profile or the repository currently being scanned. Invalid early entries also consumed the entire input budget despite producing no projected output.

Changes

Priority-aware projection

scanPreflightCodexConfig now accepts the active repository path as optional context.

Projection order is now:

1. the selected profile, when it is an own entry in profiles;
2. the active repository, when it is an own entry in projects;
3. the remaining entries in their existing deterministic insertion order.

The priority entry is still subject to every existing name, path, type, capability, and trust-level validation. It is reserved only when it produces valid projected data.

Accepted-entry limits

The 256-entry limits now count accepted projected entries rather than raw input entries.

For profiles, an entry counts only when:

• its name passes the safe profile-name boundary;
• its value is an object;
• it contains at least one supported projected execution setting.

For projects, an entry counts only when:

• its path passes the safe-string and absolute-path boundaries;
• its value is an object;
• its trust level is exactly trusted or untrusted.

Invalid and empty entries no longer prevent later valid entries from reaching preflight.

Active repository propagation

The normalized repository path is now passed into every scan-specific projection:

• the private readable config-preflight.toml used by the capability helper is rewritten for the repository before the scan starts;
• the scan recipe stores the same repository-aware projected configuration.

This also handles a reusable persistent runtime scanning different repositories: each scan refreshes the readable preflight file with its own active project before the helper can consume it.

Existing safety boundaries preserved

The change retains the existing projection restrictions:

• credentials and credential-like keys or values remain excluded;
• unsupported profile fields remain excluded;
• only capability-related execution settings are projected;
• only trusted/untrusted project metadata is retained;
• project paths must remain safe absolute paths;
• the complete sanitized configuration remains limited to 256 KiB;
• priority lookup uses own properties and does not follow prototype entries.

Tests

Added regression coverage for:

• 256 valid unrelated profiles followed by the selected profile;
• 256 valid unrelated projects followed by the active repository;
• preserving both priority entries while keeping each collection at 256 accepted entries;
• 256 invalid profile entries before 256 valid profiles;
• 256 invalid project entries before 256 valid projects;
• confirming that invalid entries do not consume the accepted-entry budget;
• an end-to-end scan runtime projection with 256 unrelated projects followed by the current repository;
• parsing the actual private preflight TOML and confirming that the current repository retains its trusted value.

Existing secret filtering, capability projection, persistent runtime, config-size, and scan orchestration tests continue to pass.

Verification

• pnpm run types
• pnpm run format
• pnpm run build
• focused API orchestration tests
• PATH="/opt/homebrew/bin:$PATH" pnpm run test

Full suite: 471 passed, 6 expected platform/integration skips, 0 failed.

[rajpratham1]

This pull request improves preflight configuration generation by prioritizing the active profile and active project before applying the existing projection limits. The new prioritizedEntries helper preserves the selected configuration while still enforcing the maximum number of serialized profiles and projects, preventing the active context from being omitted when large configurations are present. The changes are applied consistently where the preflight configuration is generated, and the accompanying tests verify both prioritization behavior and continued handling of invalid entries and projection limits. Based on the visible changes, the implementation is focused, preserves existing safeguards, and no blocking issues are apparent.