bug(llc): work products carry no attribution, are unregistered in store_authority, and the workspace lease has no caller #17496

Problem

Two records in autobot-backend/llc/models/ cannot back the claims made about them. Filed
together because they sit in the same directory and would be one PR under the one-file-one-owner
rule; both are integrity gaps in the LLC model layer, not features.

1. A work product has no attribution, and what little it has is deleted on cleanup

autobot-backend/llc/models/work_product.py:20-65 is the only deliverable/artifact table in the
repo (code / document / report / plan / screenshot / pr_link). It carries no
attribution column at all — no author_agent_id, no created_by, no contributor. Its only
link to the producing run is heartbeat_run_id, which is nullable with ondelete="SET NULL"
(:41-45), so ordinary run cleanup silently erases the last trace of who produced an artifact.

WorkProductService.create() (llc/services/work_product_service.py:22-45) accepts title and
content_text as caller-supplied prose and persists no attribution for either.

The parent LLCWorkItem does have created_by_agent_id / author_agent_id
(llc/models/work_item.py:132-133, :210-211, :248-249), but these are plain nullable columns
written by whichever service call passes them in (work_item_service.py:230-239, :276-277,
:1018-1027) — never re-derived from or validated against a run record before display.

2. LLCWorkProduct is not a registered concept

autobot_shared/store_authority.py:13-33 states rule 1: "Every persisted concept names its
system of record." system_of_record() (:268-289) raises KeyError for anything undeclared.
The STORE_AUTHORITY table (:75-265) registers llc_work (:106-121) but does not name
work-product rows as a concept. A persisted concept is therefore live without a declared authority,
which is precisely what the module exists to prevent.

3. LLCWorkspaceLease is a complete model with no acquisition code

autobot-backend/llc/models/workspace_lease.py:32-78 defines a workspace lease properly — unique
path (:49), owner (:52), expires_at / released_at / release_reason (:62-69),
is_live() (:71-75). Nothing acquires it. Greps for LLCWorkspaceLease / workspace_lease
outside the model, its own test, its migration and the models/__init__.py export return nothing,
and llc/scheduler/project_disposal_sweep.py — the reaper named in the model's own docstring —
does not reference it. Only is_live() is exercised, by workspace_lease_test.py:29-50 against a
hand-built in-memory instance.

Per the standing rule that anything resembling debris is unfinished work, this is a wire-it-in
item: the design is already correct and tested in isolation, it simply has no caller.

Acceptance criteria

• A work product's producing agent is recoverable after the originating run row is deleted — either an attribution column that survives, or heartbeat_run_id no longer SET NULL.
• Attribution shown for a work product is derived from, or validated against, a run/lineage record rather than trusted from the caller.
• LLCWorkProduct (or an enclosing concept that explicitly covers it) is registered in STORE_AUTHORITY with its system of record and any projections named.
• LLCWorkspaceLease has a real acquisition/release path with at least one production caller, or its retirement is justified by evidence that the concern is fully served elsewhere — not deleted merely for being unreferenced.
• project_disposal_sweep.py honours the lease its docstring already claims it does.

Notes on prior art in this repo

services/knowledge/lineage_service.py:100-127 already implements a correct depth-bounded,
cycle-guarded ancestor walk (explicit depth bound at :116 plus a seen set at :115-118, with
a two-node cycle exercised at test_lineage_service.py:247-248). If derived attribution is built,
that walk is the pattern to reuse — but note parent_run_id currently exists only for KB synthesis
(services/knowledge/synthesis_provenance.py:40,69); no agent or subagent run record carries one,
so a delegated worker's output cannot currently be traced to its lead's scope.

Provenance

Found while comparing AutoBot against an external agent harness that derives a deliverable's
attribution and project scope from its append-only run log at read time — keeping the agent's prose
but never the agent's claim about who helped or what it belonged to — so that a card cannot name a
collaborator the log cannot back. Analysis:
docs/research/host-adjudicated-completion-evidence-harness.md.