[lhjl-j]

Closes #7780

What this PR does / why we need it?

In community/source builds that set neither MAXKB_HMAC_SIGNED_SERIALIZER_SECRET_KEY
nor MAXKB_SECRET_KEY (and ship no xpack), the Celery HMAC serializer falls back
to uuid.uuid7(), which returns a uuid.UUID object. Both secure_dumps() and
secure_loads() call .encode() on that value, so every task publish/consume raises
AttributeError: 'UUID' object has no attribute 'encode'. The dispatch site swallows
the exception, so documents stay at "pending / 0 segments" with no visible error.
Reported in #7780 against source HEAD 2ac52b3; the same code is on v2 and v3.

Summary of your change

One line in apps/ops/celery/hmac_signed_serializer.py: str(uuid.uuid7()) instead
of a bare uuid.UUID as the fallback secret. No other file, dependency, config key,
schema or runtime path changes. When either env var is set, or xpack overrides the
key, behaviour is unchanged. This PR targets v3, the branch used by recent merges;
the file blob is identical on v2 and v3.

Please indicate you've done the following:

• Made sure tests are passing and test coverage is added if needed.
  Not checked: I did not run the MaxKB Django/Celery test suite (that stack and
  uuid-utils/kombu are not available in my Windows environment). Equivalent
  local evidence is under Evidence below. No test file is added: this module has
  no unit-test directory and the change is a single fallback expression.
• Made sure commit message follow the rule of Conventional Commits specification.
• Considered the docs impact and opened a new docs issue or PR with docs changes if needed.
  No docs impact: no new setting is introduced and the two existing env vars are unchanged.

What Problem This Solves

All Celery tasks fail to be delivered on a source-built community deployment with
default configuration, because the signing key is not a string.

User Impact

Document uploads, vectorisation and any other queued work silently stay pending.
After this change the fallback key is a valid string and task signing works out of
the box; users who already configure a secret see no difference at all.

Why This Change Was Made

hmac.new() needs bytes; .encode() only exists on str. The smallest correct
fix is to convert the generated UUID at the point where it is used as a default,
matching the reporter's suggested fix in #7780. I deliberately did not add a new
setting, change the xpack override, or introduce startup validation, because those
are separate design decisions and this PR is scoped to the reported failure.

Evidence

Local verification (Python 3.13, standard library only), loading the real file
with only uuid_utils.compat and kombu.serialization stubbed and xpack forced
absent. uuid.UUID from the stdlib is the same type uuid_utils.compat.uuid7()
returns.

• red-on-base, no env vars: AttributeError: 'UUID' object has no attribute 'encode'
  at secure_dumps().
• green-on-fix, no env vars: _local_secret_key is str; secure_dumps() returns
  58 bytes and secure_loads() round-trips the original object.
• no regression: with MAXKB_HMAC_SIGNED_SERIALIZER_SECRET_KEY=dev-secret, base and
  patched both produce str keys and an identical 58-byte signed payload.
• ast.parse and compile pass on the patched file; exactly 1 line changed;
  UTF-8 without BOM, LF only.

Limitations: no Django / Celery / Redis / uuid-utils / kombu runtime here, so the
full product suite and an end-to-end worker round trip were not run. The
verification is at the serializer module level. CI on this PR is the first full run.