fix(rest/python): read signing_keys[] where the schema places it and drop the ucp.keys[] mirror

[vishkaty]

Fixes #227

This is the Python twin of #226, the Node fix for the identical defect
named in #225. Both servers reached it by the same two steps, called out
in that issue: here #122 introduced the wrong reader and #169 added the
matching mirror, as #162 and #179 did on the Node side.

Observed vs expected

This server declares UCP_VERSION 2026-04-08
(routes/discovery_profile.json). At that pin,
source/discovery/profile_schema.json $defs/base requires ucp and
separately declares signing_keys as a top level sibling of ucp; that
schema defines no keys field anywhere. discovery.py published
signing_keys[] correctly at the top level but also mirrored it into a
nested ucp.keys[] with no schema basis at any pin, and _extract_keys()
in ucp_signing.py read only that nested field. Since ucp is required on
every real profile document, a reader that looks inside ucp whenever it
is present can never see a top level sibling field on any real document,
so the verifier could not resolve the schema correct field the same
server publishes.

Fix

• ucp_signing.py: _extract_keys() now reads the top level
  signing_keys field directly instead of descending into ucp first.
  Comment states the schema citation and flags that when this server
  moves UCP_VERSION to 2026-08-25, the field name must move to keys in
  the same change, per ucp#566.
• routes/discovery.py: the ucp object no longer carries a keys
  member. Top level signing_keys[] is unchanged.
• dependencies.py: doc comment fixed, keys[] to signing_keys[].
• README.md: the two lines describing key discovery updated to match,
  keys[] to signing_keys[] in the request signature section, and the
  webhook section no longer claims the ucp.keys[] mirror.
• ucp_signing_test.py: ProfileFetchTest and ExtractKeysTest rewritten
  around the schema correct top level shape; new tests prove nested
  ucp.keys/ucp.signing_keys are not read, and that a top level
  keys[] (the 2026-08-25 name) is not read yet either, since this
  server has not moved its declared version.
• signature_integration_test.py: the shared good profile fixture used by
  the request-signature verification tests moved from
  {"ucp": {"keys": [...]}} to {"ucp": {}, "signing_keys": [...]},
  matching the schema correct shape. This fixture was missed by an
  initial grep for .keys since it is a bare dict key, not an attribute
  access.
• integration_test.py: test_profile_publishes_the_webhook_signing_key
  now asserts ucp.keys is absent instead of asserting it is present.
• client/flower_shop/signing.py: LocalProfileServer, the counterparty profile owned by
  the demo happy path client, moved from the same nested
  ucp.keys shape to top level signing_keys, so the sign then verify
  loop it exists to demonstrate actually round-trips against the fixed
  reader.

Verification

• TDD throughout: a standalone reproduction against the unfixed code
  confirmed both the read side and write side defect first (mirroring
  the linked issue), then every new assertion was confirmed red for the
  stated reason before the fix and green after.
• ucp_signing.py unit tests: 77/77 before, 80/80 after (3 new tests).
• The discovery integration test
  (test_profile_publishes_the_webhook_signing_key): passing before and
  after, with its assertion strengthened from requiring the mirror to
  forbidding it.
• Two kill tests on the final branch, each reverting one piece of the fix
  in isolation with the new tests kept: reverting _extract_keys to the
  old nested ucp.keys read fails 4 tests in ucp_signing_test.py; reintroducing the ucp.keys
  mirror in discovery.py fails the discovery test. Both restored to green
  after.
• Live round trip: booted the server, fetched the live
  /.well-known/ucp document, confirmed ucp.keys is absent and top level
  signing_keys[] is present, confirmed the fixed _extract_keys
  on this same server resolves the served document, and validated the
  document with Python jsonschema (Draft202012Validator, real $ref
  resolution across the full vendored release/2026-04-08 schema tree)
  against source/discovery/profile_schema.json: VALID.
• Ran the demo happy path client, which signs every request and
  publishes its own JWK through a local profile server, against the
  fixed server with --allow_insecure_profile_urls: the server logs
  "RFC 9421 signature verified" for every signed request, proving the
  full sign then verify loop this demo exists to show now round-trips
  end to end.
• pre-commit (pinned .pre-commit-config.yaml) run on every touched file:
  clean.

Notes for reviewers

• ucp-sdk resolves unbounded from pip in rest/python/server/pyproject.toml.
  A fresh uv sync on unpinned main today resolves ucp-sdk 0.5.0 and the
  server fails to import (ModuleNotFoundError), independent of this
  change; this reproduces Fresh sync resolves ucp-sdk 0.5.0 and the Python server fails to import #221, already filed with a fix in fix(rest/python): bound ucp-sdk below 0.5 until the server targets v2026-08-25 #222. All
  verification above pins ucp-sdk to 0.4.6 locally to get a working
  environment, matching what fix(rest/python): bound ucp-sdk below 0.5 until the server targets v2026-08-25 #222 proposes; this PR does not touch
  pyproject.toml, since that bound belongs to fix(rest/python): bound ucp-sdk below 0.5 until the server targets v2026-08-25 #222.
• With that pin, the full pytest run fails 117 on unfixed main and 117 on
  this branch, with the FAILED test set byte-identical (confirmed with a
  diff of the sorted FAILED lines); passing goes 140 to 143, exactly the
  3 new tests. The 117 are a separate,
  pre-existing pydantic validation error in checkout payload
  construction (FulfillmentMethodCreateRequest and ShippingDestination),
  unrelated to key discovery and not touched by this PR. Flagging for
  visibility rather than folding an unrelated fix into this change.
• The Node PR (fix(rest/nodejs): read signing_keys[] where the schema places it and drop the ucp.keys[] mirror #226) also removed three capability catalog entries with
  no backing schema and widened a TypeScript field type. Neither applies
  here: the Python discovery_profile.json never declared those
  capabilities, and there is no static type system to narrow.