fix(confluence): surface unverified restriction checks instead of failing open silently

[lsimons]

_user_can_update returned True on any exception. It is the last layer of
the managed-elsewhere cascade — the one that asks Confluence whether page
restrictions make a page read-only for you — so a transient API error, an auth
problem, or an unexpected response shape produced "you may update this page" and
the push proceeded.

Four of the five cascade layers are local comparisons against configuration and
are genuine guarantees. The fifth is a network call that degraded to permission.
Restrictions are precisely the mechanism protecting pages somebody actively
does not want overwritten, so the check most likely to matter was the one that
could silently stop applying — and an unverified check was indistinguishable
from a clean pass.

Approach: still fails open, no longer silent

Failing closed would mean a Confluence outage blocks all publishing, which is
worse. So the behaviour is unchanged and the visibility is fixed.

_user_can_update now returns bool | None, where None means the API call
raised; it logs a warning at that point, with the exception in scope, rather
than guessing. ManagedClassification carries a new
restriction_check_unverified flag, and SyncSummary carries a count.

The flag lives on the classification rather than in an out-parameter because
every call site — the bulk sync path and the four single-page CLI paths
(mutate.py, update.py, export.py, publish_office.py) — already receives a
ManagedClassification back from classify_page. A collector would have needed
plumbing into paths that have no SyncSummary at all.

What an operator now sees

Warning log:

could not check page restrictions for page 111: network error

Sync summary:

Restriction check unverified: 3 — pushed without confirming update permission (Confluence restriction API call failed; see warnings above)

And a matching section in the generated commit message.

The except Exception is deliberately not narrowed: the point is that any
failure becomes visible, not that some do.

Spec

docs/spec/S26-managed-elsewhere.md read as though all five layers were equally
strict guarantees. It now states the guarantee/advisory split, the fail-open
rationale, and the new visibility mechanism, and the "no override mechanism"
section gained a clarifying sentence so it does not read as contradicting the
fail-open language (that section is about overriding a confirmed match — a
different axis).

Tests

test_api_error_is_unverified_not_allowed,
test_classify_fails_open_and_reports_unverified_on_api_error,
test_classify_logs_warning_on_restriction_api_error,
test_classify_unrestricted_page_not_flagged_unverified,
test_classify_restricted_page_still_refused_when_check_succeeds, plus summary
formatting and record_managed_skip coverage in
tests/confluence/sync/test_types.py and test_events.py.

Follow-up in a separate PR

docs/guide/04-safety.md should carry the same guarantee/advisory split. It is
owned by the in-flight blacklist-enforcement change (#50) to avoid two PRs
editing the same file, and will be updated there.

Fixes #53

Co-Authored-By: lsimons-bot bot@leosimons.com