feat(ashby): incremental job sync, custom field writes, and application lifecycle ops - #6703

Summary

Extends the Ashby connector so a scheduled job/req sync can run incrementally, and adds the write path needed to annotate reqs and retract applications.

Reads

• list_jobs accepts Ashby's syncToken and returns it as nextSyncCursor, turning a scheduled sync from O(all reqs) into O(changed reqs). Ashby only returns the token once the last page is drained, which the param description states.
• list_job_postings gains includeUnpublishedJobPostings, plus the posting status field. Without status a caller cannot tell a returned draft from a published posting, which makes the flag useless.

Writes (new operations)

• customField.setValue / setValues — the only way to annotate a job or req, since Ashby has no job notes and no job tags. Writing null clears a value, so the annotation is reversible.
• application.delete — requires candidatesDelete, a module permission separate from candidatesWrite.
• application.changeSource — corrects source attribution on programmatically created applications.
• candidate.anonymize — strips PII; the record itself remains, because Ashby exposes no candidate deletion endpoint.

Bug fix found while testing against a real Ashby org

• ashbyErrorMessage rendered Ashby's documented errors: [{message, parameter}] shape as [object Object], hiding the real cause. That is the form a 403 for a missing module permission arrives in.

Destructive-write safety

null clears a custom field, so every write here requires explicit intent before it can destroy data. This matters because the block's required markers only cover the editor: on the agent path a model calls the tool directly, so tools.config.params never runs and validateRequiredParametersAfterMerge skips a param marked not-required.

• set_custom_field_value rejects an absent or blank fieldValue; an explicit null still clears.
• change_application_source requires unsetSource to clear, and rejects a source ID and an unset request together — preferring either one silently discards the other. Ashby has no "leave unchanged" mode, so setting and clearing are the only two intents and exactly one must be expressed. The editor cannot produce the pair: the Source ID field is conditioned off while the clear switch is on.
• set_custom_field_values rejects an empty array locally rather than relying on Ashby.

The custom field value parser is deliberately narrow rather than a blanket JSON.parse, which corrupts real text: 1e999 becomes Infinity and serializes back out as null — a clear; long numeric ids lose precision past 2^53; prose starting with { turns into an object. Only the literal keywords, {/[/" prefixes, and exactly round-tripping numbers decode.

On the sync cursor's name

Ashby calls it syncToken. Surfacing it under that name renders it [REDACTED] in block output, because syncToken matches the /^.*token$/i deny-list in redaction.ts — and an incremental sync is unusable if the operator cannot read the cursor the next run needs.

An earlier revision of this PR fixed that by exempting syncToken from redaction globally. That was the wrong trade: it would have stopped redacting that field name product-wide, in any current or future integration, across execution traces, block output, the console, and telemetry — and the sharp edge was this block's own Sync Token input, where an operator pasting an API key would have had it stored verbatim.

redaction.ts is untouched by this PR. The output is named nextSyncCursor instead, which is what it actually is — an opaque resumption marker, the same class as the cursor and nextCursor fields the redactor already leaves alone. This connector already translates Ashby's wire vocabulary on the way out (limit→perPage, results→jobs). The wire name and the request param stay syncToken, matching Ashby's docs, and the input keeps being redacted, which is the protective behaviour. A test pins the invariant: syncToken is sensitive by name, nextSyncCursor and nextCursor are not.

Test Coverage

Ashby-surface tests went 4 → 142. Full suite: 25,129 passed, 41 skipped, 0 failures (1,875 files). Every commit typechecks independently.

Verified live against a real Ashby production organization, and end-to-end through the workflow editor:

• The sync cursor is returned only on the last page (confirmed two ways: a 2-page walk and a perPage=1 walk), and replaying it returns a strictly smaller result set.
• A custom field value can be written and then cleared with null, confirmed by reading the object back both times.
• includeUnpublishedJobPostings returns a strict superset, with status reporting Published / Draft.
• 11 distinct real Ashby error payloads all render readably. Every one was [object Object] before this branch.
• A 17-block edge-case workflow exercised stale/garbage sync tokens, perPage bounds, all five fieldValue encodings, empty and single-element setValues, and the three permission/not-found error paths.

apps/sim/tools/ashby/ashby.live.test.ts is committed but inert by default:

ASHBY_LIVE=1 ASHBY_API_KEY=... bunx vitest run tools/ashby/ashby.live.test.ts

Add ASHBY_LIVE_WRITES=1 for the write phase. Note that vitest.setup.ts stubs global fetch for every file in the app, so the live file restores the real implementation and asserts the restore worked — without that guard the whole suite silently passes against a mock.

Review

Greptile 5/5. One Cursor Bugbot finding — a source ID and an unset request could be supplied together and the body preferred the source ID, turning an intentional clear into a set — fixed by rejecting the pair rather than picking a winner, and by making the editor unable to produce it.

A Codex prototype-pollution concern was investigated and refuted: the redactor builds a fresh object via Object.entries, and JSON.parse never invokes the __proto__ setter.

Known gaps

• The API key available for testing lacked candidatesDelete, so delete_application and change_application_source have error-path-only live verification. Their success paths are covered by mocks. In particular change_application_source's explicit-null unset is proven against mocks but not against the live API.
• delete_application's { applicationId } response shape comes from Ashby's OpenAPI spec, not an observed live response, for the same reason.
• Eight other Ashby list_* tools still understate perPage as "(default 100)" when Ashby caps at 100 and silently truncates. Pre-existing; only list_jobs was corrected here to avoid widening scope.
• Five other Ashby list_* tools still expose a syncToken output, which is redacted for the reason described above. Pre-existing, and renaming them would break any workflow already chaining the value, so it is left for a separate change.
• candidate.anonymize's response is persisted to execution traces like any other block output. If the endpoint echoes the pre-anonymization record, log retention could outlive the erasure. That is a platform-level retention question, not specific to this diff.

Evals

No prompt-related files changed — evals skipped.