chore(deps): upgrade @pkcprotocol/pkc-js 0.0.83 -> 0.0.85

[Rinse12]

Bump @pkcprotocol/pkc-js from 0.0.83 to 0.0.85 (latest on npm).

Upstream changes

v0.0.84

• feat(pkc): cancel in-flight community fetches via abortSignal, publication.stop() and destroy() (feat(pkc): cancel in-flight community fetches via abortSignal, publication.stop() and destroy() pkcprotocol/pkc-js#276)

v0.0.85

• feat(challenges): add validateChallengeSettings and core optionInputs validation (feat(challenges): add validateChallengeSettings and core optionInputs validation (#283) pkcprotocol/pkc-js#288)
• feat(challenges): publish opt-in public challenge options in the community record (feat(challenges): publish opt-in public challenge options in the community record (#282) pkcprotocol/pkc-js#287)

Note on the 0.0.85 upgrade note

settings.challenges[] is now validated against each challenge file's optionInputs on the edit, community-creation and start paths:

• edit() with an undeclared option key, a missing required option, or an undeclared publicOptions entry now throws (ERR_CHALLENGE_SETTINGS_VALIDATION_FAILED_FOR_CHALLENGES) instead of silently saving.
• A community with such config already persisted emits one error event per invalid challenge on every start, carrying {challengeIndex, challengeName, communityAddress}. The community still starts.

Worth checking whether this repo's community edit / community create paths surface that aggregated error usefully, and whether any live community config trips it.

Plan

• Bump the dependency (exact version), regenerate the lockfile
• npm run build && npm run build:test
• npm run test:cli green
• PR, CI green, merge

[Rinse12]

PR #135 opened.

• Bump the dependency (exact version), regenerate the lockfile — lockfile diff is pkc-js only
• npm run build && npm run build:test — clean
• npm run test:cli — 43 files, 341 passed, 1 skipped, 0 failed
• CI green, merge

The 0.0.85 validation did catch one thing: test/cli/mintpass-integration.test.ts configured @bitsocial/mintpass-challenge with no options, but the package marks chainTicker, contractAddress and requiredTokenType as required. Since default in optionInputs is a UI hint core never applies, that config is now rejected on edit(). Fixed by passing the three options explicitly, using the package's own runtime fallbacks so challenge behaviour is unchanged. No other call site affected.

[Rinse12]

Released as 0.19.93 and deployed.

• CI green on all four checks, merged (chore(deps): upgrade @pkcprotocol/pkc-js 0.0.83 -> 0.0.85 #135).
• The master release run was initially blocked by an unrelated CI bug — the windows job hit the 20m cap inside "Verify global install from pack", which skipped the gated release workflow. Re-running the job cleared it; root cause is tracked in ci: Windows "Verify global install from pack" takes 8-13m and intermittently blows the 20m job timeout, blocking releases #136.
• bitsocial update install on the production host: 0.19.92 -> 0.19.93, pkc-js 0.0.83 -> 0.0.85, service restarted cleanly.

Post-deploy verification

• 17/17 communities auto-started, all still started: true; RPC responsive.
• Zero challenge-settings validation errors. Predicted in advance: before upgrading I pulled all 17 communities' challenge configs and ran 0.0.85's three checks against each challenge file's real optionInputs — all 30 entries passed, no missing required options, no undeclared keys, no publicOptions in use anywhere.
• A full IPNS republish cycle across all 17 communities completed with no errors.
• Steady state: no errors in a 10-minute window; CPU and RSS normal.

One new log-level regression worth noting

pkc-js 0.0.84's abort-cancellation work ("cancel in-flight community fetches via abortSignal, publication.stop() and destroy()") produces new error-level log lines at startup:

pkc-js:pkc:client-manager:pubsubSubscribeOnProvider:error Failed to subscribe to pubsub topic (...) due to error DOMException [AbortError]: This operation was aborted
pkc-js:local-community:sync:error Failed to sync community <addr> due to error, DOMException [AbortError]: ...
pkc-js-rpc:pkc-ws-server:error RPC server Received an error on pkc instance DOMException [AbortError]: ...

Confirmed new: 0 occurrences across the four previous daemon logs (including an 11MB one spanning days), 6 in the first minute of the new one.

It appears cosmetic rather than functional — the sequence for each affected community is subscribe succeeds -> "Successfully auto-started" -> 16ms later a redundant in-flight subscribe is aborted and logged as an error. Both affected communities started normally and are serving. So this looks like a deliberate cancellation being surfaced at error level instead of being swallowed, including on the RPC error channel that clients observe.

Not fixing it here since it is upstream behaviour, but it is worth reporting to pkc-js — noisy :error lines for an abort that is working as designed will send someone chasing a non-bug.