Implement transformation stage in BuildCompiler orchestrator

[Gonza10V]

Summary

• implement BuildCompiler.transformation(...) with a clear structured input contract
• support transformation inputs from either assembled Plasmid objects or plasmid ComponentDefinition inputs
• generate deterministic transformation outputs including:
  • SBOL references for transformation module, activities, and transformed strain implementations
  • JSON intermediate payload for OT-2 chemical transformation execution
  • protocol/log/instructions placeholder bundle for downstream artifact packaging
• add private helpers _resolve_transformation_inputs and _build_transformation_protocol_bundle
• re-export BuildCompiler in buildcompiler.__init__
• add unit tests for nominal input paths and input-validation errors
• document transformation API entry point in README

Testing

• ruff check src/buildcompiler/buildcompiler.py src/buildcompiler/__init__.py tests/test_buildcompiler_transformation.py ✅
• python -m unittest tests/test_buildcompiler_transformation.py ⚠️ fails in this environment due missing sbol2
• uv run python -m unittest tests/test_buildcompiler_transformation.py ⚠️ fails due blocked network while resolving dependencies (pydna/PyPI)

Notes

• This PR intentionally scopes changes to Phase 1 (transformation) only.
• Phase 2 (plating) and Phase 3 (full_build) remain to be implemented in follow-up PRs.

---

Codex Task

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 33e11a282c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Generate a unique transformation module ID per invocation

This module ID is derived only from chassis_name, so any second call to BuildCompiler.transformation(...) with the same chassis on the same sbol_doc will attempt to add the same ModuleDefinition identity again and fail due to duplicate SBOL identities. That blocks the documented multi-stage workflow where transformation is run more than once (e.g., after different assembly stages) unless callers manually change chassis_name each time.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Reuse existing plasmid implementations for direct inputs

For plasmid_inputs, this always creates and adds an Implementation named <displayId>_impl when the plasmid is not in indexed_plasmids, but it never checks whether that implementation already exists in self.sbol_doc. If the same direct input is processed again (or already has an implementation with that ID), the unconditional add causes a duplicate-identity failure and aborts transformation.

Useful? React with 👍 / 👎.