fix(cli): read OpenAI FileObject via attribute access, not subscript

[chuenchen309]

Describe your changes

openai.types.FileObject is a Pydantic model, not a dict/TypedDict — it isn't subscriptable. generate_file_table() (backing instructor files list) and upload() (backing instructor files upload) both read it with file["id"]-style indexing, so every invocation of either command crashes:

$ OPENAI_API_KEY=dummy uv run python -c "
from openai.types import FileObject
from instructor.cli.files import generate_file_table
f = FileObject(id='file-abc123', bytes=1024, created_at=1700000000,
                filename='t.jsonl', object='file', purpose='fine-tune', status='processed')
generate_file_table([f])
"
TypeError: 'FileObject' object is not subscriptable

The sibling instructor/cli/jobs.py's generate_table() already reads the analogous OpenAI SDK object via attribute access (job.id, job.status, ...), confirming files.py is the outlier, not an intentional pattern.

Fix: file["id"] → file.id (and bytes/created_at/filename/purpose) in generate_file_table, and response["id"] → response.id in upload() (same bug, client.files.create() also returns a FileObject).

Issue ticket number and link

None found — searched open PRs/issues touching cli/files.py, no overlap.

Checklist before requesting a review

• I have performed a self-review of my code
• If it is a core feature, I have added thorough tests. (CLI utility, not core — added a focused unit test)
• If it is a core feature, I have added documentation. (bug fix, no behavior/doc change needed)

Testing

• Added tests/cli/test_files.py::test_generate_file_table_uses_attribute_access; confirmed (via git stash) it fails with the exact TypeError against the pre-fix code, passes after.
• ruff check, ruff format --check, ty check all clean on the changed files.
• Added a CHANGELOG.md entry under [Unreleased] / Fixed per CLAUDE.md's PR guidelines.

AI disclosure

Developed with AI assistance (Claude Code), which located the crash via a search across instructor/cli/ for functions untouched by any test, and noticed both call sites shared the same root cause. I reviewed the diff, independently confirmed the fix against the sibling jobs.py pattern, and ran the test/lint/type checks myself before opening this PR.

[jxnl]

Consolidated and shipped in #2495. Closing this focused patch as superseded; thank you for the contribution.