feat(playbooks): add evidence-based Ingress TLS expiry triage

[biggdawg320]

What & why

Related to #13; claims only the Ingress TLS/certificate-expiry topic in #13 (comment). Leaves the umbrella issue open.

Add TlsCertificateExpired, a triage-only playbook for a certificate actually served to an Ingress client. It requires endpoint/termination ownership, SNI/hostname, certificate identity and trusted time before diagnosing expiry. It distinguishes expired intermediates, clock skew, future validity, external termination and a renewed Secret that is not yet served. No Secret dumping, private-key output, verification bypass, automatic renewal or RBAC expansion.

The Go error says "expired or is not yet valid" in both cases: its trigger requires the same-line timestamp and is after detail. Other triggers recognize explicit curl/Python/OpenSSL expiry errors. They select a guide when that text is supplied to the matcher; they do not introduce client/log ingestion or an automatic expiry monitor. detect: null is intentional.

Type and scope

• New playbook, documentation and tests in v4; root documentation counts regenerated.
• New tests run red first: 5 failed / 14 passed before adding the playbook.
• Positive expiry cases and negative healthy, future-validity, unknown-CA, hostname-mismatch, generic handshake/503 and cross-line cases.
• Existing human approval and secret-handling boundaries retained. Certificate/Secret changes are guidance for an authorized operator only.

Validation

• Final 178 focused tests pass on both Python 3.12 and 3.13: new TLS tests, existing playbooks/PDB/StatefulSet, all-trigger reachability and doc-claims tests.
• Ruff passes over the exact CI scope; Linux-targeted mypy passes (193 source files).
• File-mode gate passes (963 indexed files, using an LF-normalized copy of the existing gate under Git Bash); syntax and encoding gates pass (569 tracked Python files); roster passes (14 contributors).
• Generated doc counts verified after staging the new tests; MkDocs builds with existing missing-link/anchor warnings. Whitespace checks pass.
• Full Windows suites are not green. Python 3.12 server: 80 failed / 5392 passed / 106 skipped / 6 errors. Python 3.13 server: 81 failed / 5391 passed / 106 skipped / 6 errors. CLI: 10 failed / 739 passed on each interpreter. Server failure/error names match the previously recorded Windows baseline except the 3.13 doc-count failure; that count was regenerated after adding the new test file to the index and passes in both final focused runs. CLI failure names match the previous baseline. This is comparison against recorded baseline logs, not a fresh unchanged-base run. No full-suite rerun after the final documentation-count correction.
• Local staged tree exactly matches the published tree 9b88ff7.

Notes for reviewers

No live cluster, endpoint probe, LLM call or paid service used. Routing tests verify candidate selection, not a production expiry diagnosis. Source references: https://go.dev/src/crypto/x509/verify.go and https://kubernetes.io/docs/concepts/services-networking/ingress/#tls .

Prepared and validated with substantial OpenAI Codex assistance under the account owner's direction.

[github-actions]

🎉 Thank you for your first pull request to KubeIntellect.

Please read this one thing — it will look like something is broken, and it isn't:

On a fork PR from a first-time contributor, GitHub runs no CI at all until a
maintainer clicks "Approve and run workflows". Your PR will sit with no checks
and a blocked merge box. That is expected and it is not your fault. You don't
need to do anything — a maintainer will approve the run.

While you wait, the things most likely to come up in review:

• Did you run the gates? make setup from the repo root runs six of the nine
  checks main requires (ruff, mypy, both test suites, file modes, syntax
  warnings) and needs no cluster and no API key. The remaining three — the
  install smoke test and both suites on Python 3.13 — run only in CI, so a
  green local run does not guarantee a green PR.
• Does your change include a test that fails before it and passes after?
• If your change touches a command that emits a diagnosis, report, or summary:
  please run it against a deliberately absent resource (a made-up id, no
  cluster) and confirm it refuses rather than returning a plausible-looking result.
  This is the one failure mode this project cannot ship, and CI cannot catch it.
• Substantial AI assistance is welcome — please just
  disclose it
  in the description so reviewers know where to look.

Contributors are credited in CHANGELOG.md and in the release notes.