fix: [SDK-5192] detect push credentials from non-secret fields

[sherwinski]

One Line Summary

The credentials and setup skills now decide credential presence from non-secret fields of GET /api/v1/apps/{app_id}, not from the plaintext credential fields.

Linear: SDK-5192. Related server change: CORE-4599.

Motivation

The team plans to strip apns_p8, apns_certificates, fcm_v1_service_account_json, and gcm_key from the view-app response; which are all fields that plugin reads from currently. After the server change, a configured platform would read as unconfigured, the agent would start a portal walkthrough the user does not need, and the 409 disambiguation would trust a wrong Step 1 state. Every presence field in the new plan exists in the response today, so this change is safe to ship before the server change.

Scope

• references/api-reference.md: new "View an app" section. It names the presence fields (apns_env, apns_key_id, apns_team_id, fcm_sender_id, chrome_web_origin), the null / "" / absent rule, the fcm_sender_id vs chrome_web_gcm_sender_id trap, and the cross-check-only status of channels.push.platforms. It also forbids android_params.js as a pre-upload cross-check, because that read primes the CDN cache on a fresh app.
• scripts/onesignal_api.py cmd_app: prints platforms.{apns,fcm,web}.configured, platforms.apns.auth_type (p8 / p12 / null), and a cross_check object with a mismatch flag. Replaces keys_present. The script still never prints values.
• skills/credentials/SKILL.md: Step 1 item 1 and the 409 disambiguation note point at the script verdict and the presence fields.
• skills/setup/SKILL.md: the Step 3 "Check what's configured" item runs the script and names the fields for the no-Python curl path.
• skills/credentials/api-uploaded-credentials.md: removes the "Verifying which apps still use legacy" section (gcm_key read).
• Version bump 1.1.0 → 1.1.1 in the 3 version fields.

Not in scope: the verify skill (it does not read the view-app response), and any dependency on future state fields such as apns_p8_state.

Testing

Local checks from AGENT.md, all green:

• python3 -m py_compile scripts/*.py
• python3 -m json.tool on the 4 JSON files
• portability grep on skills/ and references/: no output
• python3 scripts/package_directory_bundle.py --check: bundle check passed (version 1.1.1; nothing written)
• rg 'apns_p8"|gcm_key"|fcm_v1_service_account_json"' skills references scripts: no reads left

Offline test of cmd_app with a stubbed _get (script outside the repo, removed after the run). 5 cases passed: p8 + FCM, web-only (chrome_web_gcm_sender_id set, fcm_sender_id null), no platform keys at all, p12 with empty strings, and a channels.push.platforms mismatch. The output contained no field values.

Not done in this PR, and needed before merge:

• Live run of onesignal_api.py app <app_id> against a p8 + FCM app, a web-only app, and an app with no platforms. No app-scoped key was available in the session.
• The behavior evals that cover the credentials and setup skills, per AGENT.md check 7. Record the verdicts and session IDs here.

Affected code checklist

• Skills (skills/credentials, skills/setup)
• Scripts (scripts/onesignal_api.py, scripts/checkpoint.sh version only)
• References (references/api-reference.md)
• Manifests (version bump)
• Templates
• CI / workflows

Checklist

• Commit subject uses a conventional prefix
• No internal ticket IDs in skills, scripts, or references
• No secrets in the diff
• The 3 version fields agree
• Eval run recorded (owner to run)

[kalley]

Clean change. Failing closed on a body that isn't a JSON object was a good call. Approving on the understanding that the live run and the evals from the description happen before merge. One small note inline.

Minor: scripts/onesignal_api.py:196-197 repeats the module docstring and what _present already shows.

[kalley]

If only one of apns_key_id / apns_team_id is set, this reports p12. The reference says p12 means both are empty. Should the half-set case be null instead? That case is rare, so it doesn't block.

[abdulraqeeb33]

Two fallbacks still fail open. onesignal_api.py app returns status: error when the body is not a JSON object, and the credentials skill treats that as presence unknown. The no-Python curl in setup, and the raw GET in credentials, can record that same failure as unconfigured. That is the before-state the 409 recovery rule reads as "your upload landed."

[abdulraqeeb33]

The no-Python curl -fsS | grep path treats a failed read as not configured. curl -f writes no body on 401, 404, or 5xx, and a non-object 2xx greps to nothing, which is the same signal as absent presence fields. Step 2 then starts the credentials skill, and that skill records the platform as unconfigured. A later 409 on the recovery re-call counts as success only when the platform was unconfigured before the first attempt, so a failed read can be reported as a landed upload.

Dropping -f, and treating a non-zero curl status or a non-object body as presence unknown, would match the script's status: error path.

[abdulraqeeb33]

The raw-GET fallback says to inspect the presence fields and nothing else, with no check that the response was a 2xx JSON object. A 401 body or a non-object 2xx has those fields absent, which this paragraph reads as not configured. The script path fail-closes. Item 7 covers a hard GET failure, but it fights this sentence.

Applying the presence fields only after a 2xx JSON object, and leaving Step 1 unset otherwise, would keep the 409 disambiguation on a real before-state.