First publish after start stalls up to 120s in a diagnostic-only IPNS resolve when the node's kubo has no record for the key

[Rinse12]

Problem

resolveIpnsAndLogIfPotentialProblematicSequence (ipns-publishing.ts:70) is awaited on the first
publish after start():

if (community._firstUpdateAfterStart) await community._resolveIpnsAndLogIfPotentialProblematicSequence();

It is diagnostic only: it resolves the community's own IPNS key and logs when the resolved CID
disagrees with updateCid. It changes nothing about what gets published. But it calls
resolveIpnsToCidP2P(..., { timeoutMs: 120000 }), and a name with no record cannot satisfy that, so
the publish stalls for up to two minutes before proceeding exactly as it would have anyway.

Its guard, if (!community.updateCid) return, correctly skips a community that has never published.
What it does not cover is a community that has an updateCid but whose key has no record on this
node's kubo:

• a community restored from exportCommunity onto a different node (its db carries updateCid, that
  kubo has never published the key),
• a record that lapsed or was garbage-collected while the community was down,
• any host migration that moves the db but not the kubo datastore.

Measured at ~60s in a test on the local kubo daemon. The publish then succeeds normally.

Correction to how this was first reported

I first described this in #237 as something every minter rotation pays. That was wrong, and I have
corrected the PR thread. In the rotation case the updateCid had been adopted from another instance
through #238, which is what defeated the guard. With #238's trigger avoided, the same suite runs in
2.4s total. The scenarios above are the genuine ones, and they are narrower.

Suggested fix

Two changes, either of which helps, and they compose:

1. Gate on the node's own publishing history rather than on updateCid. LAST_IPNS_RECORD
   (ipns-publishing.ts:397) records the last record this node published for this key. If it is
   absent, this node has never published this key and the resolve has nothing to compare against, so
   skip it. That is a precise signal, where updateCid only says "the community has published at some
   point, somewhere".
2. Cap the timeout. When a record does exist it comes back from kubo's own datastore in
   milliseconds, so the 120s budget only ever pays out in the failure case. A few seconds is enough,
   and the catch already treats a failure as "nothing to report".

Running it unawaited in the background is a third option and would unblock publishing too, but it
trades a bounded wait for a floating promise whose lifetime and error handling then have to be
managed, and the log arrives after the publish it was meant to warn about. Not doing the lookup when
it cannot say anything seems better than doing it out of band.