feat(ecosystem): compliant Praxis/Hexis integration + vendored build

Bring the Nexus/Praxis/Hexis integration in line with
MAVEN_ECOSYSTEM_ARCHITECTURE.md:

- Praxis over HTTP: drop the in-process praxis.db open (praxisstore/
  praxistools) and call praxisd's /api/v1/tools/* API via a new praxisClient.
  Honors the "no component reads another's DB" invariant (AC#12).
  PraxisConfig.DBPath -> URL.
- Hexis confirmation gate: mutating capabilities (ReadOnly=false) now park a
  bound pendingHexis confirmation and require a spoken "да" before executing;
  read-only run immediately (AC#7, no auto attention->action).
- Capability safety: >1 verb match is ambiguous -> ask instead of firing the
  first; ambiguous Nexus resolution asks for clarification (AC#2).
- Correlation IDs on Hexis execute, recorded in the cross-service trace.
- Bug: importance arrives as JSON float64 over HTTP, not int.
- Tests: confirm-gate, decline, read-only, and ambiguity paths.

Build: vendor/ bakes in the hexis client (replace-directed at a sibling repo
outside the Docker context); Dockerfile builds from vendor and no longer
`go mod download`s the unreachable replace paths.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

vendor/modernc.org/sqlite/HACKING.md

@@ -0,0 +1,65 @@
+## Tagging and releases
+
+Please do not tag commits unless all builders at
+https://modern-c.appspot.com/-/builder/?importpath=modernc.org%2fsqlite are
+happy.
+
+Unlike most modernc.org repositories, this one is deliberately NOT
+auto-tagged: builder.json sets "autotag": "<none>". Many projects depend on
+modernc.org/sqlite, so letting the build bots tag it automatically is too
+risky. Releases here are tagged manually by the maintainer, once all the
+builders above are green.
+
+## CHANGELOG
+
+Because releases are tagged manually (see above), the top of CHANGELOG.md can
+run ahead of the actual git tags: a version section may be written and dated
+when the work lands on master while the tag itself is pushed later. Before
+assuming a version is released, check the real latest tag with
+
+    git ls-remote --tags origin
+
+Keep all not-yet-tagged work in a SINGLE pending section at the top of
+CHANGELOG.md. Do not open a new "vX.Y.Z" header per merge request - that splits
+one pending release across several version numbers. Add each merge request's
+entry to the existing pending section, grouped with related work, and let the
+maintainer set the final version number and date when the release is actually
+tagged. The next version is the one after the latest tag reported by the
+command above, not after whatever header currently sits at the top of the file.
+
+## Integrating merge requests
+
+The canonical repository is GitLab cznic/sqlite; the GitHub mirror does not
+auto-sync merge requests, and the "merge request !NNN" references in
+CHANGELOG.md are GitLab MR numbers.
+
+Land a contributor MR by fetching its head ref and merging it with a merge
+commit:
+
+    git fetch origin refs/merge-requests/<iid>/head
+    git merge --no-ff FETCH_HEAD
+
+GitLab publishes every MR's commits at refs/merge-requests/<iid>/head
+regardless of which fork the source branch lives on. Merging --no-ff keeps the
+contributor's original commit SHAs and author metadata, and because the MR's
+head commit becomes reachable from master, GitLab automatically flips the MR to
+"Merged" once master is pushed.
+
+Do NOT land an MR by downloading its .patch and running git am: that rewrites
+the committer and the commit date, producing a new SHA that GitLab cannot match
+against the MR's source branch. The MR then has to be closed by hand and shows
+as "Closed" rather than "Merged", which reads as "rejected" to anyone scanning
+the list.
+
+Match the merge-commit message GitLab itself uses:
+
+    Merge branch '<source-branch>' into 'master'
+
+    <substantive subject> (#<issue>)
+
+    [Closes #<issue>]
+    See merge request cznic/sqlite!<NNN>
+
+Include the "Closes #<issue>" line only when the MR actually closes an issue;
+omit it for follow-ups. <source-branch> is the contributor's branch name on
+their fork.