docs: add verified actor integration for claims, refine future considerations

Update Future Considerations to document the specific decision on how
claim_item should integrate with JWKS verification: verified actor.id
is authoritative when available, self-reported agentId is trusted when
JWKS is not configured. This is a targeted integration, not blanket
verification gating.

Clarify that verification gating (reject on failed verification) is
not currently planned — the accountability-not-access-control design
is intentional for the database-per-tenant model.

Relates to #117

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

Author: jpicklyk

SECURITY.md

@@ -168,5 +168,5 @@ This means that in deployments where non-Claude-Code clients connect to the serv
 
 ### Future Considerations
 
-- **Verification gating**: A future enhancement could optionally reject operations when actor verification fails, converting the accountability layer into an access control layer for high-security deployments. This would be opt-in to preserve the current low-friction single-team experience.
-- **Claim identity validation**: When the claim mechanism (#117) is implemented, `claim_item` release operations should validate that the caller matches the `claimedBy` identity server-side, rather than trusting the `agentId` string alone. This is an intra-team operational guardrail, not a tenant isolation concern.
+- **Verification gating (opt-in)**: A future `auditing.require_verified_actor: true` flag could optionally reject write operations when actor verification fails, converting the accountability layer into an access control layer for high-security deployments. This would apply to write operations only (`advance_item`, `manage_notes`, `claim_item`) and would be opt-in to preserve the current low-friction single-team experience. This is not currently planned — the existing design (accountability, not access control) is intentional and sufficient for the database-per-tenant isolation model.
+- **Claim identity and verified actors**: When the claim mechanism (#117) is implemented, `claim_item` should prefer the verified `actor.id` from a JWKS-validated JWT over the self-reported `agentId` parameter. When JWKS is configured and a verified actor is present, the verified identity becomes authoritative for claim ownership. When JWKS is not configured, `agentId` is trusted as-is. This is a targeted integration between the claim and verification layers — not a blanket authentication gate. See #117 for the full identity resolution table.