Problem

#1046 (#1045) deletes an upload once it is older than the retention period of a multi-user deployment. The owner has no way to know when: the upload's metadata carries created_at and nothing about its end, and the retention period is a server setting the client cannot read.

Evidence

feat/issue-1045-upload-limits (on top of main @ 9aed0c4):

• service/uploads_service.py upload_metadata_body: upload_id, format, encoding, size_bytes, original_filename, created_at.
• service/upload_limits.py: the cutoff is now - retention_days, known only to the service.

Asked for in the review of #1046: "사용자가 언제 지워지는지 미리 알 방법이 없습니다 — 업로드 메타데이터에 만료 시각을 싣고 Studio 가 보여 주는 것을 후속 이슈로".

User / Product Impact

A saved spec that names an upload stops building after 30 days with "upload not found", and nothing warned its owner. The review recommends starting a first deployment with KPUBDATA_BUILDER_UPLOAD_RETENTION_DAYS=0 until this is in.

Scope

• Builder: POST /uploads and GET /uploads/{upload_id} say when the upload expires (expires_at, null when retention is off or the deployment is single-user). Additive contract change.
• Studio: show it where an uploaded file is chosen and where a saved spec names one (kpubdata-studio issue to follow once the field exists).

Non-goals

• Extending or renewing an upload.
• Periodic clean-up between restarts.

Acceptance Criteria

• An upload's metadata carries expires_at equal to created_at plus the retention period in force
• It is null when nothing will delete the upload
• The contract declares the field

Required Verification

V1; V2 for the contract.

Notes

Follow-up asked for in the review of #1046.