Cross the stdlib 0.19 boundary; bump sigil-web to 0.17.0

sigil-web pinned sigil-nrepl "^0.16", whose exclusive ceiling is 0.17.0. The absorbed-standalone fix ships in sigil-nrepl v0.17.1, which consumes sigil-repl from the monorepo instead of the archived standalone, so no consumer reaching sigil-repl through sigil-web could see it.

Crossing that boundary is a multi-range bump, not a one-line change: the runtime floor and every dependency that still declares an absorbed standalone have to move together, or the relock manufactures duplicate module providers instead of removing them.

  sigil             ^0.17   -> ^0.19    nrepl 0.17.1 requires ^0.19
  sigil-nrepl       ^0.16   -> ^0.17.1  first release off the standalone
  sigil-http        ^0.18.0 -> ^0.18.4  first release without sigil-socket
  sigil-test        ^0.19            }  keeps the runner pair on one line
  sigil-test-runner ^0.19            }  0.17.3 declares sigil-ansi

Each floor names the release where the behaviour works, not the series that contains it. That matters most for sigil-nrepl: "^0.17" would also admit v0.17.0, which still declares codeberg:sigil/sigil-repl and sigil-socket, so a lock written before v0.17.1 existed resolves the archived standalone back in and builds green with three duplicate providers. "^0.17.1" is what actually holds the property.

Minor, not patch, and the number is the whole point. A dependency's sigil: floor is not enforced during resolution -- only the root package's is -- so a consumer left on the 0.17 or 0.18 runtime that picks this up resolves a 0.17 stdlib beside 0.19-line packages and builds green with no diagnostic. A patch release would have been taken automatically by everyone pinned ^0.16, and that silence is exactly what pre-1.0 minor-as-major exists to prevent. 0.17.0 makes consumers opt in. sigil-nrepl 0.17.0 -> 0.17.1 and sigil-http 0.18.0 -> 0.18.4 crossed the same boundary as patches; on this mechanism they most likely shipped the same hazard quietly, so they are not a precedent to keep.

The drag is sigil-test-runner, not sigil-test: sigil-test at 0.17.3 has an empty dependencies list. sigil-test-runner declares sigil-ansi directly and reaches sigil-version and sigil-git through workspace sigil-build and sigil-deps.

Full lock inventory, 18 entries -> 12:

  removed  sigil-ansi 0.16.0   sigil-args 0.16.0    sigil-docs 0.16.1
           sigil-git 0.16.0    sigil-hooks 0.16.1   sigil-socket 0.16.0
           sigil-version 0.16.0
  added    sigil-sqlite 0.16.2
  changed  sigil-crypto 0.16.3 -> 0.16.5   sigil-http 0.18.0 -> 0.18.4
           sigil-lib 0.17.3 -> 0.19.3      sigil-nrepl 0.16.1 -> 0.17.1
           sigil-repl 0.16.1 -> 0.19.3     sigil-stdlib 0.17.3 -> 0.19.3
           sigil-test 0.17.3 -> 0.19.3     sigil-test-runner 0.17.3 -> 0.19.3
           sigil-tls 0.16.3 -> 0.16.6

sigil-repl stays in the lock but changes provenance: it now resolves from url codeberg:sigil/sigil with package-selector sigil-repl, not the archived standalone repository.

Two of those entries are more than bookkeeping. sigil-tls 0.16.6 bounds the TLS handshake as a whole rather than per read, makes tls-write yield instead of block, and fixes a descriptor leak, so HTTPS behaviour moves with it. sigil-sqlite vendors a SQLite amalgamation that is compiled into a build.

Verified by looking rather than by a green suite: the five absorbed _pkg manifests are absent post-build where all five were present pre-build, and the build log shows exactly one producing package for all six absorbed modules, now sigil-stdlib where it was previously the standalone. The suite passes 173 assertions, which is recorded but proves nothing here: a tree carrying the archived standalone and three duplicate providers passes the same 173.